快速閱讀本文
-
如果將WebRTC僅僅作爲協議轉換，而不進行編解碼，簡直是殺雞用牛刀，更是對如此複雜框架的褻瀆，因爲轉碼能夠實現：
-
適配不同的接收者的編碼格式需求。
-
自動調整碼率，以適應不同的網絡帶寬，並且不需要重新請求。
-
如果發生丟包，能夠自動重發關鍵幀。
-
-
Kurento服務器能夠實現：
- 能夠根據接收者的要求，創建不同的編碼格式（比如VP8和H.264）。並且，相同的編碼格式能夠分發給不同的觀看者——即相同格式只編碼一次，以降低性能消耗。
-
性能測試
-
轉碼方式，性能消耗會隨着數量的增加而直線上升。透傳方式，數量增加對性能影響很小。
-
VP8使用的內存量是H.264的兩倍，同時也使用更高的CPU。同樣，VP8使用的CPU似乎隨着比特率的提高而略有增長，而H.264的CPU使用率似乎不受輸出比特率的影響。
-
碼率自動調整：VP8波動更大，好處是短時間提供更高的視頻質量。H.264更加穩定，同時需要花更多的時間達到最好的視頻質量。
-
視頻源的質量必然會影響服務器解碼性能，應該根據理想情況下用戶最低可接受的視頻質量做出選擇。
-
向多個用戶提供同一路碼流是，CPU和內存的性能消耗幾乎沒有變化。
-
以下爲原文
有關將IP攝像機與基於WebRTC的流解決方案集成的主題是本博客之前涉及的一個主題：互操作性WebRTC和IP攝像機。從那篇文章開始已經有一段時間了，所以在這篇文章中，我們想對上一篇文章中處理過的所有基本概念進行某種回顧，以及對人們在做出更多技術決定時的新觀點。設計一種架構，其中IP攝像機通過Kurento Media Server作爲WebRTC端點發布。
WebRTC傳輸
嘗試將IP攝像機與WebRTC應用程序集成時，首先要擔心的是視頻和音頻流之間的兼容性。WebRTC規範對支持哪種視頻編碼格式（也稱爲編解碼器）非常明確，並且瀏覽器通常也符合標準所說的內容：任何符合標準的實現都必須能夠同時支持VP8 和H.264 視頻編解碼器（參見 RFC7742 / 5. Mandatory-to-Implement Video Codec）。
因此，符合WebRTC的瀏覽器將能夠識別以VP8或H.264編解碼器編碼的視頻。幸運的是，這兩個編解碼器幾乎是行業中的事實上的標準，因此大多數（即便不是全部）IP攝像機已經支持它們（特別是H.264，這是很多視頻中最常見的編解碼器）。
聽起來不錯，不是嗎？
從理論上講，這可能意味着大多數攝像機生成的H.264視頻應能夠作爲WebRTC流直接傳輸，如下所示：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-t8QjRC24-1574416259698)(https://lh3.googleusercontent.com/5m4LfgrkS1VVUi3QgvlVIxOzqxNx7ZcaEMtKojJ6BuibJMm-9X13TJi_UZvy794_EUxlnsXQrQKu2rANJK4SSwYxWlwBFdw1WPGfij-biql1owZXcrbtzo5PwAqVjX276jyoFDOo)]
這看起來不錯，並且實際上這樣的網關的資源消耗將是最小的，因爲它將只是傳輸之間的轉換，而不做任何編解碼的處理。
但是，這種簡單的設置存在一些隱患：如果有些接收者不支持IP Camera的編碼格式，該怎麼辦？如果網絡不可靠並且觀看者沒有足夠的帶寬觀看視頻，該怎麼辦？
WebRTC不僅僅是一個“透傳”的功能。如果真是這樣，那麼該標準的複雜性就沒有多大意義了！我們也可以直接將RTSP流發送給觀衆。實際上，WebRTC的重點是能夠以安全，可靠和有效的方式提供視頻，這必須包括能夠在網絡連接不穩定且遭受各種現實問題的情況下做出適當的響應，例如網絡擁堵，數據包丟失以及其他類型的網絡異常行爲。
因此，WebRTC支持多種反饋機制，允許任何觀看者向發送者“彙報”當前的網絡狀況：
[img)(https://lh4.googleusercontent.com/yR5CsJMnOJJax8aVcel81tURfM4F1bNnHh4Cp5smQiYKpiN8NNmhtnl6ssW2cedBfcXWp8_HQHAXWIoLO6Ml_1TwLxFWUvGwd8aHJgXbVfcppeCyiNUvzLgn-5SAj3aJ2VHuUEXN)]
圖2：完整的媒體網關配置，允許轉碼並對不良的網絡條件做出反應
通過引入一對解碼器和編碼器——通常稱爲轉碼，網關能夠解決編解碼器兼容性和網絡可靠性問題。然後，中間編碼器可以根據反饋信息做出相應的反應：
-
當網絡擁塞時，接收器將SRTCP控制數據包發送回網關，其中包括REMB消息。這些消息包含可用於視頻接收的實際帶寬的估計，網關相應地調整其編碼比特率。
-
當某些數據包丟失時，接收器還會發送包含PLI消息的 SRTCP數據包，要求網關重新發送視頻關鍵幀，以使其從丟失的視頻數據中恢復。
例如，常見的情況是網絡變得擁塞，（通過REMB消息）指示視頻編碼器降低比特率並生成質量較低的視頻作爲響應。因此，該視頻會更小，可以更好通過擁塞的網絡進行傳輸。
WebRTC帶來的反饋方法對於大多數典型的現實世界網絡來說都可以很好地工作，但是它要付出代價：現在媒體網關需要做更多的工作——轉碼。這通常是一個值得折衷的選擇。
使用Kurento Media Server
到目前爲止，我們已經描述了將視頻從攝像機（或任何其他視頻源）傳輸到WebRTC用戶（例如Web瀏覽器）的典型場景以及相關的困難。陳述的問題是所有解決方案共有的，任何網關都必須以一種或另一種方式處理它們。
Kurento Media Server提供了涵蓋所有上述要點的綜合解決方案。PlayerEndpoint可以執行從各種來源獲取視頻流以及可選的媒體轉碼的操作。然後，與WebRTC通信相關的所有內容都由WebRtcEndpoint處理。僅通過這兩個組件，可以涵蓋上一章討論的所有重要細節，並且您將擁有一個適用於IP攝像機的完全正常工作的WebRTC媒體網關：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-IPW1KWb4-1574415825353)(https://lh3.googleusercontent.com/zKuJHewlHdRieE6AnfuXexvj1exclqE3o4MNXrwbclJJbjLqEGOL6hKPawaZ0Ti9A6gxRIJb8rPW-tAjeS_JgOV_e2VZOLDry6ktwckV5NhXps0V9LEskj8rDrQlMdsHO6-yUxDm)]
圖3：使用Kurento Media Server實現IP Camera到WebRTC媒體網關
該圖中的關鍵元素是Agnostic轉碼，在Kurento中是由稱爲agnosticbin 的組件執行的。該組件封裝了轉碼操作，如前所述，在該處處理SRTCP數據包，從而支持比特率調整（基於REMB消息）或重新生成視頻關鍵幀（基於PLI消息）。
同樣在agnosticbin 元素中，將根據接收者的要求，選擇最佳的視頻編碼器。比如，原始視頻爲H.264編碼，但是接收方僅支持VP8，則此時視頻將被轉換爲VP8。
另一個有用的功能是，WebRtcEndpoint可以調整最大和最小視頻比特率。這樣，自動調整比特率時將被限制在我們設定的範圍內。
Agnosticbin編碼樹
在實現我們的應用程序時，我們可能希望同一條流具有多個接收者。這是否意味着每個觀看者都需要獨立的轉碼過程？
這是一個好問題，答案並不絕對。每個觀看者使用獨自的轉碼過程確實是理想的解決方案，因爲它允許每個人根據自己的需要調整比特率。但是，副作用就是過大的資源浪費，以至於根本無法承受大量的觀看者。
Kurento實施了一種折衷解決方案，其中每種編解碼器類型都執行一次代碼轉換過程，然後將所得視頻分發給所有使用者——前提是相同的編碼格式。Kurento內部的agnosticbin 元素實現了該功能，該樹涵蓋所有使用者的編解碼器要求，而無需兩次執行相同的工作：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-DQVOAmOO-1574415825353)(https://lh3.googleusercontent.com/yerHuLogvPMHDzm1vKHBiH0n-ofalgCtZ7GA0S0S7C-AQRMkzF3q1Yt_cGX_Orgl9LdWp7FMT1ygd0psGD7oJushVAOq0MrktyNeaqdGM-WmVuDUzkcdQDIfi4NpROqsJcuJVPoO)]
圖4：2個VP8和2個H.264消費者的Agnosticbin編碼樹
最終的結果是您的服務器將不會使用比實際需要更多的CPU。就CPU使用率而言，對視頻進行編碼是一項非常昂貴的任務，但是一旦完成，每個其他WebRtcEndpoint 使用者都會增加很少量的額外資源使用量。
性能比較
在將WebRTC應用於商業項目時，我們往往會遇到下面一些問題：
- 在性能上，使用VP8或H.264編碼的視頻之間是否有實際區別？
- 在WebRTC網關中執行轉碼實際上需要消耗多少性能？
- 如果必然要重新編碼，是否需要IP攝像機具有極高的質量？
在本節中，我們將比較幾種可能的配置，以及帶來的影響，以試圖闡明其中的一些問題。
本節中測試結果是基於以下配置：
- CPU：Intel Core i5-5675C @ 3.10GHz（4核）
- 內存：16 GB DDR3
- 網絡：100 Mbps LAN
最後，在軟件方面，以下測試具有以下特徵：
- 包括模擬不利網絡條件的測試使用慢速網絡幫助程序腳本。
- 所有結果的4個RTSP流的持續時間爲4分鐘。在測試期間，每分鐘一次向系統添加一個新的IP攝像機流到WebRTC管道，在測試結束時總共有4個RTSP流和4個WebRTC使用者。這也是爲什麼所有CPU /內存使用情況圖都帶有4個“步驟”的樓梯，因爲每個步驟都對應於添加新的RTSP源和WebRTC使用者。
- 所有測試均在WebRtcEndpoint上設置了最大比特率，以將接收到的REMB帶寬估計限制在受控範圍內。
轉碼 vs 透傳
我們已經提到Kurento 負責agnosticbin 元素，以提供RTSP源和WebRTC使用者之間的視頻編解碼器互操作性。但是，轉碼過程在PlayerEndpoint 內部是可選的。這意味着僅通過使用PlayerEndpoint 的構建器參數useEncodedMedia，就完全有可能使用KMS 模擬圖1 的簡單體系結構。使用此參數時，將完全跳過PlayerEndpoint 內部的不可知元素：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-uM2LFbVI-1574415825354)(https://lh3.googleusercontent.com/kmJehlvvRcz5HLTORFlcLHEI-XSIg43qEf6v7WO6N8tQCJlfQ9vzzoDGf_urq9g7WM7g4lhH_IeKlTofiE0AcctxqcjzaYKDLGqHuC5b3Mpo-0LgYw8-tQUMKbVhv4SwpoOF10lg)]
圖5：將Kurento的播放器端點與“ useEncodedmedia”一起使用
這樣的效果是，如圖1 所示，媒體直接從源傳輸到WebRTC傳輸。當然，這具有不能使用SRTCP反饋消息來適應不同網絡條件的問題，但是它允許在IP攝像機和WebRTC使用者之間建立快速而簡單的網關。
此配置的資源消耗非常小：
| [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-73zxD4VS-1574415825354)(https://lh3.googleusercontent.com/87ALtOfRNr4-9aNlKXdlER9QlYLNryZUNXLkxe3qSKPCZycQ1F9pIpd_ZJezEn1D7nPZel-GbsSUHpMW6vbAC9fZEzJ5V_rqhnxEP5KCn6ApFsLsbMu2LBjcTEFrBDmfco3xQprv)] | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-IDQFtYHU-1574415825354)(https://lh3.googleusercontent.com/nyQgkvSQJTcRlL6yF0p9_4ljAVtC-BgHJhH5MhKDeMhqHql8jkoQhdv1hZcIWRH1wLylt-9ri0nQrEWp7Am7Ofx-ojo60BuYpjwWnFEGWcfdXdKBPUGGQXm_bpSsVqGbM17xzPud)] |
|---|---|
| 沒有轉碼的H.264 | 轉碼的H.264 |
如果網絡條件良好，則透傳是最佳選擇（例如，局域網或具有QoS功能的路由）。此模式相當於禁用了WebRTC的所有QoS相關功能。當然，CPU和內存使用量將會降至最低。但是，正如我們已經明確指出的那樣，如果發生任何網絡事故，視頻流的接收將受到以下幾個問題的困擾，例如：丟幀導致的卡頓、花屏，甚至連接斷開等。
VP8 vs. H.264
資源使用
在嘗試比較WebRTC視頻編碼的這兩種選擇時，我們可以通過不同的角度進行觀察。首先是CPU和內存使用率。我們將通過幾個圖表來看到這一點：
| [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-8nWy9mhk-1574415825354)(https://lh6.googleusercontent.com/SVgj-qbpYx-EiKqbPWCthKf8Zsj9mE7BmAYxkSI88BmnbaO8cverJv-ULpqnveMQSKeRKfv9zBEGNsAnInyVXXYxXUTk4EFTi66BWjQ0EIj0ByTkKWjtte0xWtPj5yE6i7wWujMx)] | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-sDBlZp8t-1574415825354)(https://lh3.googleusercontent.com/QkZl257mUXYWeTteQ31sPjq_7kB8k1rA5LWHhZxXgnJUfcgb0ZuXCT8TtkGdgAEiYxAsNYtupPFQ5N2It2ziZxUrSdOG_ZVwrg1HYV_55CLaEehEVZBeG9p6gkjLOpPzYVx1kR3d)] |
|---|---|
| WebRTC VP8 @ 500 kbps | WebRTC VP8 @ 20 Mbps |
| [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-PtHfLmOm-1574415825355)(https://lh4.googleusercontent.com/7mn-c3eHbZhrrE069da6lR2wKX_Ucuws8dv2M63xLuLHU3wCd_4JYrP4kFUaW_A07yG8Yilbo5H-7E0vRZhy4jBd3W-MVJgZDRR7qzcvyp4ZA3GYGn6xrvkXzE-SmhD1M7d-rKcP)] | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-MzReS9z5-1574415825355)(https://lh3.googleusercontent.com/4QOl_Jti2CaoTz4f7TuitfRPAMnKKHGXT8kGyb2O0PIHv-DdW_H9s5fKhZPHmRbCsglvSNuHCPNa6stjJ02XFUF2FZn-M3L_8ViWGu0ZgWH9RGYzhWVsuoyw8dRg_9d-Ji7sNTtW)] |
| WebRTC H.264 @ 500 kbps | WebRTC H.264 @ 20 Mbps |
VP8使用的內存量是H.264的兩倍，同時也使用更高的CPU。同樣，VP8使用的CPU似乎隨着比特率的提高而略有增長，而H.264的CPU使用率似乎不受輸出比特率的影響。
碼率自動調整（網絡暢通）
以下測試基於Chrome瀏覽器。
但是，資源使用並不是我們選擇某一編碼器的唯一標準。
讓我們從客戶端的角度看發生了什麼，並分析從Chrome瀏覽器發送到媒體服務器的REMB消息的內容
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-icLN7mG5-1574415825355)(https://lh4.googleusercontent.com/C_AbrVQCTnuvQ4sQe-OJlmVCroaIoD3Q_bqEV2ilYLeetVRi3BbsSxSW1ryD8cU2F3kmyvpEQz0TDGLfpRDFSXtNCtqE7HdpszBseYtvPcnzGJP0Xo4PgnB8SgpGk_h5yaWPDWoZ)]
WebRTC VP8 REMB比特率提高到允許的最大值（20 Mbps）
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-FUyUiUOq-1574415825355)(https://lh4.googleusercontent.com/T2Olh0SVyQyypGYV-RPu3F5ftPFbB6nY07hWCOAVCuqbervhtbB6JGmL5mzg9SoycEOyXtQab0A2QP1zeyAWxi_hRe0j6z8FP56EGZ9zNi7omq4X-QpVkjPFmMD5fX2ZdQit6nMC)]
WebRTC H.264 REMB比特率提高到允許的最大值（20 Mbps）
VP8更具侵略性，能夠達到20 Mbps的最大可用比特率。這種侵略性意味着，當網絡出現擁塞時，它有可能超過實際可用帶寬，下面的測試將會看到這一現象。無疑，這種機制的好處是VP8能夠在非常短的時間內提供更好的質量。
H264的反應時間要慢得多，在4分鐘的測試中，它只能達到大約2.5 Mbps，即使最大可用帶寬是20 Mbps。這意味着，當使用H.264時，Chrome需要花更多的時間來達到最高的質量水平。另一方面，當網絡擁塞發生時，它的緩慢意味着一個更穩定的變化，如下圖所示。
碼率自動調整（網絡擁塞）
以下測試基於Chrome瀏覽器。
當發生網絡擁塞時，消費者可用於接收視頻的帶寬將變得比平時更小，服務器應嘗試限制編碼比特率。接下來的這些圖顯示了模擬VP8 的5 Mbps 和H.264的2.5 Mbps 最大帶寬的效果：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-COKVTUpl-1574415825355)(https://lh3.googleusercontent.com/gfUL96wUHhWUclChEwV5kIkweS7fPElcmOxPnF9eJZShXp7F9mVUenhIxfVsA3QwmzEpznxnZnqWHR99rS76JTBwCHtFZReE89SNLmZj0Diuht3Y9cV3WLeqyLqBzftA36pifnBN)]
WebRTC VP8比特率提高到擁塞（5 Mbps）
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-tKpPOKhf-1574415825356)(https://lh6.googleusercontent.com/0f4HKoVaK_fFAa_bIN-04AxY3hDTiXd_Q9tQCNYy0QK5mUXh_pCi7lTLSktliZjRBuYfoTbOMJHObLg8t9sKttC0jZAaldC9uTb2_mkYwAYQknNAIJRI00LMx9j-_XZzdATGtf0H)]
WebRTC H.264比特率提高到擁塞（2.5 Mbps）
在這裏，我們看到了前面提到的過沖的一個清晰示例：VP8瘋狂地嘗試調整爲實際可用帶寬，但是在嘗試中它變得高於實際可用帶寬，因此REMB估算值大幅度下降，以便補償。然後，快速上升再次開始。所以波動非常大。
反觀H.264，運行緩慢且穩定，一旦將每個新用戶添加到會話中，我們甚至可以看到可用比特率略有下降。添加第二個用戶後，第一次REMB校正會非常大，但是之後，其他用戶帶來的影響非常小（ 由於實際可用的帶寬是4個消費者之間共享，每個消費者的比特率會越來越低 ）。
IP攝像機中的視頻設置
我應該將相機配置爲最高質量的影像嗎？
這是一個好問題。鑑於稍後將對視頻進行重新編碼以適應網絡帶寬，所以在原始源中設置最高的視頻質量可能會更好。
這個其實還是一個需要妥協的問題。從IP攝像機發送到Kurento的高質量視頻將意味着進行解碼需要更高的CPU和內存要求：
| [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-cW8naupw-1574415825356)(https://lh4.googleusercontent.com/f_tY2lSWCSHXMjnQeiTBG3GyE6jpivf93q3504TmErLrIUZKUiogsAgna7rTTpTU3GGBy54SRLuMHg6d74dyIh3_W00QHkug7CZr3LinUYBMkBfm5c8afa_bJ5bhjXLzebqRx0cn)] | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-mSwjqk4X-1574415825356)(https://lh5.googleusercontent.com/yK26UEXYnTAQzcuclndd2sZNaIH9JUCuYbRgu43kvNM2lyT8kO6uyCYHxrFg2odVIqVlpblYuxwN9iV9X2BjsFOAKwqXJUBG0IFRBjcHT0aXbcjI9KBJeghJgMSZLb1b4eAdMxRY)] |
|---|---|
| WebRTC VP8 @ 720p | WebRTC VP8 @ 1080p |
| [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-2cQuEgfo-1574415825359)(https://lh4.googleusercontent.com/eDNu6Zrl4LYRS1uV8AxOWe28b5IwUhLtaya55eKFYi0ULkbJM0BscPRtnmOaOG3Op670wnz0sX4SzPyxKtkQRfb15aGp_EpdgUACgpZkRQFayPe9u7W6Iy649qfnAJPSnZVmZdiv)] | [外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-FztAcn1A-1574415825359)(https://lh5.googleusercontent.com/BE7S0nDvYO-BHWgq52cbvMBw_Z3ErSy3Kt6XkWUacvmE7EjuQ949Zp0ZQi2813YuPz0dnUYNW2QRUdj24juz2UFhWmZFiYCjun8YMfKnUEcY6wQlz8Avp7lXhOA9U-dKn148j0vg)] |
| WebRTC H.264 @ 720p | WebRTC H.264 @ 1080p |
在這些測試中，來自RTSP IP攝像機的原始流首先配置爲高質量1080p，然後配置爲中等質量720p。
1080p視頻的設置如下：
- H.264 High Profile
- 1920x1080（1080p）
- 4000 kbps VBR @ 30 fps
同樣，720p視頻的配置如下：
- H.264 Baseline Profile
- 1280x720（720p）
- 2000 kbps VBR @ 30 fps
如您所見，無論我們爲最終的視頻編解碼器選擇什麼，在對WebRTC的視頻進行代碼轉換時，原始材料的原始格式都會對資源使用產生影響。
理想情況下，我們應該根據用戶最低可接受的視頻質量來做出決定，因爲當REMB比特率提高時，他們在屏幕上看到的內容最接近相機生成的原始視頻。
單攝像機，多觀衆
正如我們前面提到的，agnosticbin組件足夠聰明，可以避免對同一視頻進行多次編碼，而只是構建一個編碼“樹”，該樹可以向多個使用者提供單個編碼流。
這種設計選擇的效果是，每個編解碼器僅對CPU和內存使用量進行“付費”一次，並且隨後的使用者向計算機添加的資源使用量可忽略不計：
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-iblffDzP-1574415825359)(https://lh4.googleusercontent.com/nRLUujxAQXWqpEyX0AmI3RSr1ZdtGTBg6XN3v1A0R5ntolvUF6jZFrnbAMlP-hBvJTYrrTBU55U9Fr41EL8OxELlYmocGF4Nab5lGM_mkg58i_Qaw2iP6iSEwuhJHvyI6QK5WlDT)]
此圖顯示了持續12分鐘的測試中CPU和內存使用的演變情況，其中每分鐘將一個新的WebRTC使用者連接到同一RTSP源攝像機，總共12個使用者。如您所見，機器資源的平均使用完全由最初爲接收RTSP視頻而進行的單個轉碼驅動。
總結
在涉及大量設備和視頻配置文件的情況下，轉碼幾乎是必須的，這也是爲應對網絡擁塞所提供基本功能。但是有時很難知道哪個是我們特定情況下的最佳參數。
我們希望本文有助於使您對該主題有所瞭解，並且您可以使用Kurento來創建自己的理想產品。
編碼愉快！