問題背景：
近期看到一篇音視頻技術週刊的一篇文章《12 Things to Consider When Building a Live Streaming App》，感覺寫的還不錯，是Red5官網掛出來的一篇博客，對設計、構建一個流媒體平臺系統有一定的參考意義。這裏簡單翻譯一下，以饗讀者。其中Red5是一個採用Java開發的Flash流媒體服務器，與之對標的有Nginx-Rtmp、SRS和FMS等。
打造一個流媒體平臺除了像一般後端服務要求那樣，比如性能、擴展性、可維護性以及可測試性，還有其它音視頻技術方面的考慮。作者大體從12個方面闡述了需要考慮的因素，同時我對每段意思做了言簡意賅的概括，英語比較low，所以原文還是貼出來，防止有時因爲翻譯不準誤人子弟。
Building a live streaming application requires many moving pieces. Not only is the process of live streaming complicated, but the number of companies offering to help “simplify” the process can have the opposite effect.
Let’s take a look at some of the key features you should consider in choosing a platform to build your live streaming application on.
譯：
構建一個實時流媒體應用需要很多活動組件，直播過程不僅僅複雜而且許多公司爲了能簡化這個過程，但是實際卻起到了相反的效果。
現在讓我們看看你在選擇平臺構建你的直播應用時需要考慮的關鍵特性。
瞭解更多關於音視頻&IOT，歡迎關注公衆號：智媒黑板報
1) Latency
Having the lowest possible latency is a keystone to live experiences.
Live auctions, drone guidance, event broadcasts, even basic conversations all need real-time latency. Any sort of delay between the broadcaster and subscriber will have negative consequences. High latency results in staggered conversations, spoilers and a general sense that the live event is not actually live.
In order to achieve real-time latency, you must use protocols that have been developed specifically for low latency. For browser-based apps WebRTC is really your only choice to get near real-time latency. WebRTC when handled correctly consistently achieves under 500 milliseconds of latency. That is fast enough to be nearly imperceptible.
Other efforts to lower browser based video latency including Low Latency HLS, CMAF, Apple Low Latency HLS and WebSockets and Media Source Extensions have all fallen short of delivering actual real-time latency.
For more on how WebRTC provides such low latency, check out this blog post.
If it’s a native mobile app you are building you have a few more options. RTSP is a very good protocol for mobile because the underlying video transport is RTP or its secure cousin SRTP, which also happens to be exactly what WebRTC uses. RTSP also happens to be a much simpler protocol than WebRTC better geared towards a client server model. Thus RTSP typically allows for more connections on your server endpoint making your server infrastructure scale with lower costs.
While the rest of this post talks mostly about streaming solutions based on WebRTC, the same exact principles apply to RTSP based video streaming apps.
譯：
對於直播體驗最關鍵的就是要實現低延時。實時拍賣，無人機導航，事件廣播，甚至最基本的多人對話場景都需要低延時。廣播公司和和訂閱者任何形式的延時都會產生多多少少的負面影響，對於多人對話，電視直播以及現場事件場景，高延時都會帶來不在現場的那種感覺。
爲了實現低延時，你需要使用專門爲低延時開發的流媒體傳輸協議。基於瀏覽器的應用程序，WebRTC幾乎是實現低延時通信的唯一選擇。如果能正確的使用WebRTC，那你可以實現低於500ms的延遲，這種速度快得讓你幾乎覺察不到。
像其它爲了實現基於瀏覽器低延遲通信的協議，比如低延時HLS、CMAF和WebSocket，其實都沒有真正實現實時通信。
如果你要創建一個移動APP應用，那你的選擇顯得就比較多。RTSP就是一種非常好的移動端低延時實現協議，因爲該協議底層用到的是RTP或者跟它相近的SRTP，這種協議也被WebRTC所使用。對於客戶端-服務端模型，RTSP恰好是比WebRTC更的簡單的協議，同時RTSP通常允許服務器端可以有更多的鏈接，這樣可以花費很小的成本實現擴展。
這篇文章其餘部分主要討論基於WebRTC的流媒體方案，當然討論的原則也適用於基於RTSP流媒體方案的應用程序。
注：
音視頻系統根據延時敏感性可以分爲三擋：第一擋要求音視頻延時一般低於800ms,視頻會議，遠程教育都是這類代表。這類一般用的音視頻分發協議基於UDP，基於TCP很難做到這麼低的延時。其中WebRTC方案和RTP協議是這類的代表。第二擋要求延時在1-5s,這類應用延時容忍度稍微高點，基於TCP的分發協議諸如RTMP、HLS和Dash都是可以的。最後一檔就是不對延時有啥要求，一般的點播應用。這種像優酷愛奇藝和B站都是這種。對延時的敏感性決定了不同應用背後的音視頻技術棧都不一樣，設計流媒體直播應用需要考慮的因素也不一樣。
2) Scalability
Equally important to having a low latency stream is the ability to send that out to as many people as needed. Importantly, it needs to maintain that low latency.
Some streaming platforms like Vonage Video API (formerly TokBox) switch to higher latency protocols after they meet a certain threshold, meaning that those additional viewers won’t have the same experience as those that joined earlier. While that allows them to achieve scalability, it comes with the tradeoff of high latency and a poor user experience.
However, some platforms based on traditional CDN infrastructure use HTTP based high latency protocols by default. That means none of their users get low latency at all.
In order to provide the best user experience, the challenge lies in scaling out to large audiences while maintaining real-time latency for the best user experience.
One way to solve this is by leveraging cloud networks to spin up new compute instances to create a cluster of server nodes that deliver content without the caching mechanisms that CDNs rely on. Using this approach the platform can scale to millions of concurrent users while maintaining sub 500 milliseconds of latency. This WebRTC based delivery design creates an opportunity to broadcast large sports events, concerts or other events making a much more interactive experience possible.
譯：
和低延時同樣重要的的是能夠將音視頻儘可能多的及時分發需要它的用戶，同時還要保持低延時。
一些流媒體平臺，比如Vonage Video API(以前的 ToKBox)，在併發量達到設定的閾值後，會自動將分發協議切換成高延時的協議，這意味着那些超過閾值設定值後來加入的用戶將不會用戶和加入之前用戶的體驗。雖然這允許他們實現了伸縮性，但是帶來的是高延遲和糟糕的用戶體驗。
然而基於傳統CDN基礎設施平臺雖然擁有很高的併發能力，但是他們默認基於HTTP的高延遲協議，這意味着他們的用戶也根本沒有獲得低延遲。
爲了提供最佳的用戶體驗，這個挑戰在於向大量用戶提供流媒體服務時還能保持最佳的實時低延遲。
解決這個問題的一種方法是利用雲計算啓動新的計算實例，創建一個服務器集羣。這些節點不使用CDN緩存機制來交付內容。使用這種方法可以將平臺的併發量擴展到百萬級別，同時保證了延時不低於500ms。這種基於WebRTC 的交付設計可以爲大型體育賽事、音樂會以及其它體育活動創造大量機會使得很多交互式體驗成爲可能。
注：流媒體平臺單單隻關注低延時還不行，還必須關注高併發。只有做到大量併發情況下系統依然能保障低延時纔有意義。基於傳統的CDN緩存方案，提升併發量靠譜但是不能保證低延時，這裏可用的方案比如WebRTC還是充滿了希望。
3) Efficiency
Your live streaming app needs to work efficiently so your users are not waiting around for the back end infrastructure to setup everything appropriately. Scaling out is great but without streamlining the CPU consumption of the live streams your network could be bloated with many unnecessary servers.
There also needs to be stable connection logic to ensure that clients and broadcasters are connected is a way that works well. Additional features such as relays can help optimize streaming performance as well.
Furthermore, efficient coding will result in compact streams which will streamline data delivery. This enables more streams per server and reduces the need to run hordes of servers to support large events with lots of connections.
譯：
你的實時流媒體應用程序需要高效工作，這樣你的用戶就不需要做太多和後端基礎設施不匹配帶來的工作。即使擴展性很好，但是如果不減少實時流的CPU消耗，你的網絡最終會變得異常臃腫。
除此之外，你的流媒體系統還需要穩定的鏈接邏輯以確保客戶端和廣播良好工作，另外像一些轉分發技術也可以提升流媒體平臺的穩定性。
除此之外，高效率的編碼也很關鍵，這樣會以更快的速度實現流媒體數據的在線交付。這樣做還可以增加每臺服務器傳輸流的數量，也意味着可以減少因爲需要大量鏈接而運行的服務器。
注：
實現一個高效率的流媒體系統應該從三方面優化，一個CPU的消耗，其次利用一些轉分發技術提升鏈接的穩定性，最後還要採用高效率的編碼方案。
其實低延時、擴展性和成本效率本來就是三角制約關係，一般我們要根據特殊的應用場景，進行取捨來完成流媒體系統的開發。
4) Portability
Thriving within the tech sector requires agility. Beyond responding to evolving customer expectations, there is a need to address changes within the structure of your application.
Platforms that you used to build your application can change from internal company decisions to drop features, an external merger that changes pricing, or outright going out of business. The ability to proactively respond to these changes can make or break an application, as being locked-in to a particular platform can have dire consequences.
A hosting agnostic solution with a flexible API is preferable in order to maintain flexibility. That way multiple platforms will be supported to avoid being locked-in to a single provider. AWS, GCP, Azure, and DigitalOcean are just some of the few providers with a variety of benefits and disadvantages. An API that allows you to plug into any back-end, allows you to setup your application on different systems without having to overhaul the entire infrastructure.
譯：
科技行業的繁榮需要靈活性，除了不斷要響應客戶不斷變化的需求和期望，還需要處理應用程序的結構。
用於構建你應用程序的第三方平臺常常會發生不可預知的變化，這些變化可能因爲商業決策，外部合併或者徹底停業引起。如果響應這些變化，我們的應用程序結構也會發生變化，所以我們要盡力避免被單一的平臺鎖定，因爲這會帶來可怕的結果。
爲了保持靈活性，最好使用具有靈活性的跟特定第三方無關的API，避免被單一第三方平臺鎖定。AWS、GCP、Azure和DigitalOcean是少數考慮了上述問題的服務提供商，他們提供的API可以允許你在不同的系統和平臺上集成，同時不需要你應用程序做過多的適配。
注：
爲了快速響應客戶的變化需求，提高流媒體系統的靈活性主要還是在你的程序結構設計和依賴的第三方服務上，不僅不能讓自己的平臺和特定的一家服務供應商綁定，還要集成那些水平比較高的第三方平臺。
5) ABR
Not all users will have perfect, 5G connectivity. Even those in highly connected areas can have periods of instability or throttled bandwidth.
In order to ensure the smooth delivery of video to every customer possible, responsive features such as Adaptive Bitrate (ABR) are very important. ABR allows the client to request a lower bitrate that is more appropriate to the connectivity they are experiencing at that moment.
The approach to implement ABR is quite different when dealing with real-time protocols like WebRTC. You can’t rely on simply requesting a new manifest and pulling new segment files as is done with MPEG DASH and HLS. In order to adjust on the fly with WebRTC the system needs to be able to shift to the different stream variants via information provided over a control protocol. REMB messages sent over RTCP allow the edge node to deliver just the right size stream for every network situation.
譯：
並不是所有用戶將來都能擁有完美的5G鏈接，即使高度鏈接的地區，也會存在不穩定和帶寬受限的時候。
爲了確保視頻數據能夠順利地交付給用戶，諸如自適應碼率ABR響應特性變得非常重要。ABR技術允許客戶端根據他們的連接網絡情況，可以傳輸更低碼率的視頻。
在處理像WebRTC這樣的低延時通信協議時，實現ABR技術是很不同的。不能像使用MPEG DASH和HLS那樣簡單地請求新的播放清單和提取新的文件片段即可，爲了能夠實時調整WebRTC，流媒體系統需要通過控制協議交換相關流信息，比如通過RTCP的REMB消息允許每個邊緣節點爲每個網絡情況提供正確大小的流。
注：自適應碼率是實時流媒體系統必須考慮的事情，不同的客戶端網絡情況應該提供匹配網絡情況的碼率，這樣即能保證視頻的質量又能兼顧相應的流量和帶寬，給每個用戶提供足夠優秀的體驗。ABR技術的核心是要根據傳輸流媒體的控制協議比如RTCP交換客戶端和服務端的網絡信息進行判斷當前網絡情況，進而確定應該分發的視頻碼率。
6) Modern Protocols
Keeping up to date with the latest technology is quite obviously important to a tech platform. As the phasing out of Flash has shown, well established protocols that were once dominant, can go away.
WebRTC has emerged to take the place of Flash (and RTMP) as a widely supported and effective browser based protocol. Capable of transporting live streaming video in near real-time, WebRTC is suited for the modern demands placed upon live streams.
Based on web-standards, WebRTC also enjoys the support of Apple, Google, Microsoft, Mozilla, and Opera. That support ensures that the WebRTC standard remains up to date and functional for the foreseeable future.
That being said, you also need…
譯：
對於一個流媒體技術平臺而言，跟上最新的技術非常重要，正如Flash的逐步淘汰一樣，那些曾經穩如磐石的成熟流媒體協議也會隨着時間而可能流逝。
WebRTC已經取代了曾經Flash-RTMP方案，現在已經變成一種得到所有瀏覽器廣泛支持的協議。因爲WebRTC能夠接近實時的傳輸流媒體視頻數據，這點滿足了現代實時流媒體的要求。
基於web標準，WebRTC還得到了蘋果、谷歌、微軟、Mozilla和Opera的支持。這種支持確保了WebRTC標準在可預見的未來仍然是最新的和有效的。
注：鐵打的營盤流水的兵，流媒體系統要緊跟最新技術，特別對於最新的流媒體傳輸協議。WebRTC的成功就是順應了時代的要求進而得到了幾乎所有Web瀏覽器和大廠的支持。以前基於TCP的的RTMP、RTSP、HLS等技術都會隨着時代的變遷而消退，最近像QUIC、SRT、RTP一些基於UDP的流媒體傳輸協議就得到了長足的發展。
7) Support for Legacy Systems
Even though Flash is going away, RTMP (the capable workhorse of live streaming) will still be around. As such, you will need to have RTMP to support older browsers/devices. Look for solutions with failover support to RTMP and HLS to ensure that your streams will reach all your users.
However, support for legacy protocols is not the only thing you need for compatibility.
譯:
雖然Flash技術逐漸消亡了，但是作爲流媒體曾經主力的RTMP依然存在，因此我們的流媒體系統需要支持RTMP來實現對舊瀏覽器和設備的支持。尋找這些支持HLS和RTMP的兼容性方案目的就是讓你的視頻流能夠確保到達所有的用戶手中。
同時，兼容老舊系統並不是流媒體系統兼容性的唯一，需要兼容的方面還很多，
注：
評價一個好用的流媒體系統重要一點還在於兼容性，能兼容老的客戶端和老的接入設備，不僅能兼容老協議還能兼容各種平臺抑或兼容更多的編碼方式都很重要。兼容性也是一個優秀流媒體平臺需要考慮的因素。
8) Multi-Platform Support
Your video streaming server will need to work across a variety of different devices and browsers. You wouldn’t want to alienate any of your potential customers by not supporting their device of choice. Android users are painfully aware of this whenever they hear about a cool new app that’s only available in the Apple Store.
WebRTC can be run directly in the browser without a plugin. As mentioned earlier, it has the support of the major tech players, so it can be run in Chrome, Firefox, Safari, Edge, and Opera. More importantly, you can use mobile as well as desktop browsers.
Furthermore, you should also have the flexibility of adding a native app with a mobile SDK. The ability to stream in mobile browsers or in an app, allows you to support mobile devices even if you don’t have the resources to devote to customizing a native app.
Beyond just mobile devices, you might want to support IoT devices as well. Drones, IP cameras, and VR headsets can all benefit from live video streaming. These flexible options ensure that you can stream to all the devices your customers are using.
譯：
你的視頻流服務器需要跨各種不同的設備和瀏覽器工作。你肯定不想因爲不支持你客戶選擇的設備而選擇疏遠他們。安卓用戶每當聽到一個很酷的應用只在IOS系統商店可以使用時感到非常的痛苦。
WebRTC技術不需要任何插件就可以直接在瀏覽器中跑起來運行。正如前面說的那樣，它已經得到主流技術播放器的支持，所以可以運行在幾乎任何一款瀏覽器，比如Chrome、Firefox、Safari和Edge。同時你可以使用桌面瀏覽器和移動端瀏覽器。
同時你的流媒體系統應該提供移動端SDK支持移動端能力。哪怕你沒有資源去專門定製和開發移動端APP，那你至少需要通過SDK方式讓移動端的瀏覽器和應用程序具備流媒體能力。
除了移動設備，你估計也需要支持物聯網設備，像無人機，VR設備和IP攝像頭都應該從視頻直播中獲益，這些靈活的選項確保了了你的流媒體能力可以到達您的客戶使用的所有設備。
注：
一個完善的流媒體不僅僅包括服務端能力的支持，同時需要考慮移動端、IOT等業務的支持，這樣做的目的就是爲了提供完整的端到端能力，可以跨平臺支持任何的設備和瀏覽器，這樣你的流媒體能力將無孔不入，滿足所有的客戶需求。
9) Technical Support
This may be a little counterintuitive as an argument could be made that a well built platform won’t need support. However, most people would agree that even the most well built products will need the occasional technical support.
The more flexibility and extensible features a platform offers the more having good support becomes a necessity. With customizable platforms it is essential that you receive guidance in making the most out of all the available features. Chat channels, online ticketing systems, and advanced support contracts can all be leveraged to make sure that all your needs are met.
譯：
技術支持這事有點可能違反你的直覺因爲一個良好的平臺按道理是不需要技術支持的。然而大部分人也同意即使是再好的產品也需要提供偶爾的技術支持。
平臺的靈活性和擴展性越好就讓技術支持這件事變得越必要。對於定製化的平臺，要是能充分利用所有特性那麼提供一點技術支持更是必不可少。提供技術支持的方式可以通過在線聊天，在線合同和票務的形式進行支持。
注：
一個良好的技術平臺要有一些跟客戶溝通的渠道，即使再牛逼的產品都必不可少。一來能讓客戶充分挖掘你平臺的產品特性，同時也能提供一定反饋回來指導和優化平臺。實際中你可以建立一個社區或者建立一個在線聊天系統等都可以做好這件事。
10) Customizable
“One size fits all” hardly ever does. Just because it worked for someone else, doesn’t mean it will work for you.
Those that just bought a new phone are all too familiar with this as they struggle to eliminate the bloatware pre-installed (sometimes permanently) on their new device. If you don’t need something why should you be forced to have it?
Conversely, there is the issue of needing something and not being able to get it. Whether it’s a security configuration or special feature, you need a solution that lets you build what you want with no restrictions.
譯：
一刀切或者一套標準很難奏效，因爲你的平臺適應一部分人意味着不一定另外的人。
對於買了新手機的人非常熟悉一點，就是新設備上常常會預安裝一堆東西，這些東西非常難刪除。如果有些用戶不需要這些，你爲啥讓他必須擁有這些？
相反地，有一個問題是需要某樣東西但是你卻得不到它。無論是安全配置還是特殊功能，流媒體平臺都要提供一種解決方案，讓用戶不受任何限制地構建自己想要的東西。
11) Forward Thinking Platform
Obviously, a well functioning platform is a very high priority. However, another major consideration should be how well it will continue to perform. As the recent downfall of Flash has shown, the technologies that drive live streaming can be subject to change.
There are always new standards in development. Streamlined protocols and more efficient codecs are all part of the marketplace.
A good video streaming platform doesn’t just create a product and stop. They make adjustments, respond to customer feedback and generally work to improve everything.
譯：
顯然，一個運行良好的平臺非常重要，然而，它如何持續長時間的運行也非常重要。正如Falsh最近衰落顯示的那樣，驅動流媒體直播的技術是隨時可能發生變化的。
在開發過程中總會出現新的標準，同時精簡的協議和高效的編碼器也是市場不可或缺的一部分。
一個好的視頻流媒體平臺不會因爲創造一個產品就停止腳步，應該根據客戶的反饋做出調整，以便努力的改善平臺。
注：
打造一個好的流媒體平臺需要關注市場中出現的新協議，新標準和高效的編解碼方案。只有不斷跟隨潮流，才能讓自己的系統更優秀。
12) Well Tested and Proven
There are no amount of features that will make up for a poor performing streaming platform. Extensive testing and consistent performance are important to your application.
譯：沒有多少功能可以彌補一個性能不佳的流媒體平臺。廣泛的測試和一致的性能對您的應用程序非常重要。
往期文章回顧:
音視頻解封裝：MP4核心Box詳解及H264&AAC打包方案
個人轉載內容至朋友圈和羣聊天，無需特別申請版權許可。
引用轉載該訂閱號文章，註明文章來源即可。
記得右下角點“在看”，還可以關注該訂閱號，防止遺漏推送哦
今天就說這麼多，祝您工作順利！
如果有疑問，你可以在公衆號後臺發消息諮詢我。