?問題背景：
近期看到一篇音視頻技術(shù)周刊的一篇文章《12 Things to Consider When Building?a Live Streaming App》敛瓷，感覺寫的還不錯(cuò)椅亚，是Red5官網(wǎng)掛出來的一篇博客蛔外，對(duì)設(shè)計(jì)垛耳、構(gòu)建一個(gè)流媒體平臺(tái)系統(tǒng)有一定的參考意義造虎。這里簡單翻譯一下惦费，以饗讀者。其中Red5是一個(gè)采用Java開發(fā)的Flash流媒體服務(wù)器冰抢，與之對(duì)標(biāo)的有Nginx-Rtmp、SRS和FMS等艘狭。
打造一個(gè)流媒體平臺(tái)除了像一般后端服務(wù)要求那樣挎扰，比如性能、擴(kuò)展性缓升、可維護(hù)性以及可測試性鼓鲁，還有其它音視頻技術(shù)方面的考慮。作者大體從12個(gè)方面闡述了需要考慮的因素港谊，同時(shí)我對(duì)每段意思做了言簡意賅的概括骇吭，英語比較low，所以原文還是貼出來歧寺，防止有時(shí)因?yàn)榉g不準(zhǔn)誤人子弟燥狰。
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.
譯：
構(gòu)建一個(gè)實(shí)時(shí)流媒體應(yīng)用需要很多活動(dòng)組件，直播過程不僅僅復(fù)雜而且許多公司為了能簡化這個(gè)過程斜筐，但是實(shí)際卻起到了相反的效果龙致。
現(xiàn)在讓我們看看你在選擇平臺(tái)構(gòu)建你的直播應(yīng)用時(shí)需要考慮的關(guān)鍵特性。
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.
譯：
對(duì)于直播體驗(yàn)最關(guān)鍵的就是要實(shí)現(xiàn)低延時(shí)顷链。實(shí)時(shí)拍賣目代，無人機(jī)導(dǎo)航，事件廣播嗤练，甚至最基本的多人對(duì)話場景都需要低延時(shí)榛了。廣播公司和和訂閱者任何形式的延時(shí)都會(huì)產(chǎn)生多多少少的負(fù)面影響，對(duì)于多人對(duì)話煞抬，電視直播以及現(xiàn)場事件場景霜大，高延時(shí)都會(huì)帶來不在現(xiàn)場的那種感覺。
為了實(shí)現(xiàn)低延時(shí)革答，你需要使用專門為低延時(shí)開發(fā)的流媒體傳輸協(xié)議战坤。基于瀏覽器的應(yīng)用程序残拐，WebRTC幾乎是實(shí)現(xiàn)低延時(shí)通信的唯一選擇途茫。如果能正確的使用WebRTC，那你可以實(shí)現(xiàn)低于500ms的延遲蹦骑，這種速度快得讓你幾乎覺察不到慈省。
像其它為了實(shí)現(xiàn)基于瀏覽器低延遲通信的協(xié)議，比如低延時(shí)HLS、CMAF和WebSocket边败，其實(shí)都沒有真正實(shí)現(xiàn)實(shí)時(shí)通信袱衷。
如果你要?jiǎng)?chuàng)建一個(gè)移動(dòng)APP應(yīng)用，那你的選擇顯得就比較多笑窜。RTSP就是一種非常好的移動(dòng)端低延時(shí)實(shí)現(xiàn)協(xié)議致燥，因?yàn)樵搮f(xié)議底層用到的是RTP或者跟它相近的SRTP，這種協(xié)議也被WebRTC所使用排截。對(duì)于客戶端-服務(wù)端模型嫌蚤，RTSP恰好是比WebRTC更的簡單的協(xié)議，同時(shí)RTSP通常允許服務(wù)器端可以有更多的鏈接断傲，這樣可以花費(fèi)很小的成本實(shí)現(xiàn)擴(kuò)展脱吱。
這篇文章其余部分主要討論基于WebRTC的流媒體方案，當(dāng)然討論的原則也適用于基于RTSP流媒體方案的應(yīng)用程序认罩。
注：
音視頻系統(tǒng)根據(jù)延時(shí)敏感性可以分為三擋：第一擋要求音視頻延時(shí)一般低于800ms,視頻會(huì)議箱蝠，遠(yuǎn)程教育都是這類代表。這類一般用的音視頻分發(fā)協(xié)議基于UDP垦垂，基于TCP很難做到這么低的延時(shí)宦搬。其中WebRTC方案和RTP協(xié)議是這類的代表。第二擋要求延時(shí)在1-5s,這類應(yīng)用延時(shí)容忍度稍微高點(diǎn)劫拗，基于TCP的分發(fā)協(xié)議諸如RTMP间校、HLS和Dash都是可以的。最后一檔就是不對(duì)延時(shí)有啥要求页慷，一般的點(diǎn)播應(yīng)用憔足。這種像優(yōu)酷愛奇藝和B站都是這種。對(duì)延時(shí)的敏感性決定了不同應(yīng)用背后的音視頻技術(shù)棧都不一樣酒繁，設(shè)計(jì)流媒體直播應(yīng)用需要考慮的因素也不一樣四瘫。
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.
譯：
和低延時(shí)同樣重要的的是能夠?qū)⒁粢曨l盡可能多的及時(shí)分發(fā)需要它的用戶，同時(shí)還要保持低延時(shí)欲逃。
一些流媒體平臺(tái)，比如Vonage Video API(以前的 ToKBox)饼暑，在并發(fā)量達(dá)到設(shè)定的閾值后稳析，會(huì)自動(dòng)將分發(fā)協(xié)議切換成高延時(shí)的協(xié)議，這意味著那些超過閾值設(shè)定值后來加入的用戶將不會(huì)用戶和加入之前用戶的體驗(yàn)弓叛。雖然這允許他們實(shí)現(xiàn)了伸縮性彰居，但是帶來的是高延遲和糟糕的用戶體驗(yàn)。
然而基于傳統(tǒng)CDN基礎(chǔ)設(shè)施平臺(tái)雖然擁有很高的并發(fā)能力撰筷，但是他們默認(rèn)基于HTTP的高延遲協(xié)議陈惰，這意味著他們的用戶也根本沒有獲得低延遲。
為了提供最佳的用戶體驗(yàn)毕籽，這個(gè)挑戰(zhàn)在于向大量用戶提供流媒體服務(wù)時(shí)還能保持最佳的實(shí)時(shí)低延遲抬闯。
解決這個(gè)問題的一種方法是利用云計(jì)算啟動(dòng)新的計(jì)算實(shí)例井辆，創(chuàng)建一個(gè)服務(wù)器集群。這些節(jié)點(diǎn)不使用CDN緩存機(jī)制來交付內(nèi)容溶握。使用這種方法可以將平臺(tái)的并發(fā)量擴(kuò)展到百萬級(jí)別杯缺，同時(shí)保證了延時(shí)不低于500ms。這種基于WebRTC 的交付設(shè)計(jì)可以為大型體育賽事睡榆、音樂會(huì)以及其它體育活動(dòng)創(chuàng)造大量機(jī)會(huì)使得很多交互式體驗(yàn)成為可能萍肆。
注：流媒體平臺(tái)單單只關(guān)注低延時(shí)還不行，還必須關(guān)注高并發(fā)胀屿。只有做到大量并發(fā)情況下系統(tǒng)依然能保障低延時(shí)才有意義塘揣。基于傳統(tǒng)的CDN緩存方案宿崭，提升并發(fā)量靠譜但是不能保證低延時(shí)亲铡，這里可用的方案比如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.
譯：
你的實(shí)時(shí)流媒體應(yīng)用程序需要高效工作劳曹，這樣你的用戶就不需要做太多和后端基礎(chǔ)設(shè)施不匹配帶來的工作奴愉。即使擴(kuò)展性很好，但是如果不減少實(shí)時(shí)流的CPU消耗铁孵，你的網(wǎng)絡(luò)最終會(huì)變得異常臃腫锭硼。
除此之外，你的流媒體系統(tǒng)還需要穩(wěn)定的鏈接邏輯以確蓖扇埃客戶端和廣播良好工作檀头，另外像一些轉(zhuǎn)分發(fā)技術(shù)也可以提升流媒體平臺(tái)的穩(wěn)定性。
除此之外岖沛，高效率的編碼也很關(guān)鍵暑始，這樣會(huì)以更快的速度實(shí)現(xiàn)流媒體數(shù)據(jù)的在線交付。這樣做還可以增加每臺(tái)服務(wù)器傳輸流的數(shù)量婴削，也意味著可以減少因?yàn)樾枰罅挎溄佣\(yùn)行的服務(wù)器廊镜。
注：
實(shí)現(xiàn)一個(gè)高效率的流媒體系統(tǒng)應(yīng)該從三方面優(yōu)化，一個(gè)CPU的消耗唉俗，其次利用一些轉(zhuǎn)分發(fā)技術(shù)提升鏈接的穩(wěn)定性嗤朴，最后還要采用高效率的編碼方案。
其實(shí)低延時(shí)虫溜、擴(kuò)展性和成本效率本來就是三角制約關(guān)系雹姊，一般我們要根據(jù)特殊的應(yīng)用場景，進(jìn)行取舍來完成流媒體系統(tǒng)的開發(fā)衡楞。
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.
譯：
科技行業(yè)的繁榮需要靈活性吱雏，除了不斷要響應(yīng)客戶不斷變化的需求和期望，還需要處理應(yīng)用程序的結(jié)構(gòu)。
用于構(gòu)建你應(yīng)用程序的第三方平臺(tái)常常會(huì)發(fā)生不可預(yù)知的變化歧杏，這些變化可能因?yàn)樯虡I(yè)決策镰惦，外部合并或者徹底停業(yè)引起。如果響應(yīng)這些變化得滤，我們的應(yīng)用程序結(jié)構(gòu)也會(huì)發(fā)生變化陨献，所以我們要盡力避免被單一的平臺(tái)鎖定，因?yàn)檫@會(huì)帶來可怕的結(jié)果懂更。
為了保持靈活性眨业，最好使用具有靈活性的跟特定第三方無關(guān)的API，避免被單一第三方平臺(tái)鎖定沮协。AWS龄捡、GCP、Azure和DigitalOcean是少數(shù)考慮了上述問題的服務(wù)提供商慷暂，他們提供的API可以允許你在不同的系統(tǒng)和平臺(tái)上集成聘殖，同時(shí)不需要你應(yīng)用程序做過多的適配。
注：
為了快速響應(yīng)客戶的變化需求行瑞，提高流媒體系統(tǒng)的靈活性主要還是在你的程序結(jié)構(gòu)設(shè)計(jì)和依賴的第三方服務(wù)上奸腺，不僅不能讓自己的平臺(tái)和特定的一家服務(wù)供應(yīng)商綁定，還要集成那些水平比較高的第三方平臺(tái)血久。
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鏈接突照，即使高度鏈接的地區(qū)，也會(huì)存在不穩(wěn)定和帶寬受限的時(shí)候氧吐。
為了確保視頻數(shù)據(jù)能夠順利地交付給用戶讹蘑，諸如自適應(yīng)碼率ABR響應(yīng)特性變得非常重要。ABR技術(shù)允許客戶端根據(jù)他們的連接網(wǎng)絡(luò)情況筑舅，可以傳輸更低碼率的視頻座慰。
在處理像WebRTC這樣的低延時(shí)通信協(xié)議時(shí)，實(shí)現(xiàn)ABR技術(shù)是很不同的翠拣。不能像使用MPEG DASH和HLS那樣簡單地請(qǐng)求新的播放清單和提取新的文件片段即可版仔，為了能夠?qū)崟r(shí)調(diào)整WebRTC，流媒體系統(tǒng)需要通過控制協(xié)議交換相關(guān)流信息误墓，比如通過RTCP的REMB消息允許每個(gè)邊緣節(jié)點(diǎn)為每個(gè)網(wǎng)絡(luò)情況提供正確大小的流邦尊。
注：自適應(yīng)碼率是實(shí)時(shí)流媒體系統(tǒng)必須考慮的事情，不同的客戶端網(wǎng)絡(luò)情況應(yīng)該提供匹配網(wǎng)絡(luò)情況的碼率优烧，這樣即能保證視頻的質(zhì)量又能兼顧相應(yīng)的流量和帶寬，給每個(gè)用戶提供足夠優(yōu)秀的體驗(yàn)链峭。ABR技術(shù)的核心是要根據(jù)傳輸流媒體的控制協(xié)議比如RTCP交換客戶端和服務(wù)端的網(wǎng)絡(luò)信息進(jìn)行判斷當(dāng)前網(wǎng)絡(luò)情況畦娄，進(jìn)而確定應(yīng)該分發(fā)的視頻碼率。
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…
譯：
對(duì)于一個(gè)流媒體技術(shù)平臺(tái)而言，跟上最新的技術(shù)非常重要熙卡，正如Flash的逐步淘汰一樣杖刷，那些曾經(jīng)穩(wěn)如磐石的成熟流媒體協(xié)議也會(huì)隨著時(shí)間而可能流逝。
WebRTC已經(jīng)取代了曾經(jīng)Flash-RTMP方案驳癌，現(xiàn)在已經(jīng)變成一種得到所有瀏覽器廣泛支持的協(xié)議滑燃。因?yàn)閃ebRTC能夠接近實(shí)時(shí)的傳輸流媒體視頻數(shù)據(jù)，這點(diǎn)滿足了現(xiàn)代實(shí)時(shí)流媒體的要求颓鲜。
基于web標(biāo)準(zhǔn)表窘，WebRTC還得到了蘋果、谷歌甜滨、微軟乐严、Mozilla和Opera的支持。這種支持確保了WebRTC標(biāo)準(zhǔn)在可預(yù)見的未來仍然是最新的和有效的衣摩。
注：鐵打的營盤流水的兵昂验，流媒體系統(tǒng)要緊跟最新技術(shù)，特別對(duì)于最新的流媒體傳輸協(xié)議艾扮。WebRTC的成功就是順應(yīng)了時(shí)代的要求進(jìn)而得到了幾乎所有Web瀏覽器和大廠的支持既琴。以前基于TCP的的RTMP、RTSP泡嘴、HLS等技術(shù)都會(huì)隨著時(shí)代的變遷而消退甫恩，最近像QUIC、SRT磕诊、RTP一些基于UDP的流媒體傳輸協(xié)議就得到了長足的發(fā)展填物。
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技術(shù)逐漸消亡了，但是作為流媒體曾經(jīng)主力的RTMP依然存在霎终，因此我們的流媒體系統(tǒng)需要支持RTMP來實(shí)現(xiàn)對(duì)舊瀏覽器和設(shè)備的支持滞磺。尋找這些支持HLS和RTMP的兼容性方案目的就是讓你的視頻流能夠確保到達(dá)所有的用戶手中。
同時(shí)莱褒，兼容老舊系統(tǒng)并不是流媒體系統(tǒng)兼容性的唯一击困，需要兼容的方面還很多，
注：
評(píng)價(jià)一個(gè)好用的流媒體系統(tǒng)重要一點(diǎn)還在于兼容性广凸，能兼容老的客戶端和老的接入設(shè)備阅茶，不僅能兼容老協(xié)議還能兼容各種平臺(tái)抑或兼容更多的編碼方式都很重要。兼容性也是一個(gè)優(yōu)秀流媒體平臺(tái)需要考慮的因素谅海。
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.
譯：
你的視頻流服務(wù)器需要跨各種不同的設(shè)備和瀏覽器工作脸哀。你肯定不想因?yàn)椴恢С帜憧蛻暨x擇的設(shè)備而選擇疏遠(yuǎn)他們。安卓用戶每當(dāng)聽到一個(gè)很酷的應(yīng)用只在IOS系統(tǒng)商店可以使用時(shí)感到非常的痛苦扭吁。
WebRTC技術(shù)不需要任何插件就可以直接在瀏覽器中跑起來運(yùn)行撞蜂。正如前面說的那樣盲镶，它已經(jīng)得到主流技術(shù)播放器的支持，所以可以運(yùn)行在幾乎任何一款瀏覽器蝌诡，比如Chrome溉贿、Firefox、Safari和Edge浦旱。同時(shí)你可以使用桌面瀏覽器和移動(dòng)端瀏覽器宇色。
同時(shí)你的流媒體系統(tǒng)應(yīng)該提供移動(dòng)端SDK支持移動(dòng)端能力。哪怕你沒有資源去專門定制和開發(fā)移動(dòng)端APP颁湖，那你至少需要通過SDK方式讓移動(dòng)端的瀏覽器和應(yīng)用程序具備流媒體能力宣蠕。
除了移動(dòng)設(shè)備，你估計(jì)也需要支持物聯(lián)網(wǎng)設(shè)備爷狈，像無人機(jī)植影，VR設(shè)備和IP攝像頭都應(yīng)該從視頻直播中獲益，這些靈活的選項(xiàng)確保了了你的流媒體能力可以到達(dá)您的客戶使用的所有設(shè)備涎永。
注：
一個(gè)完善的流媒體不僅僅包括服務(wù)端能力的支持思币，同時(shí)需要考慮移動(dòng)端、IOT等業(yè)務(wù)的支持羡微，這樣做的目的就是為了提供完整的端到端能力谷饿，可以跨平臺(tái)支持任何的設(shè)備和瀏覽器，這樣你的流媒體能力將無孔不入妈倔，滿足所有的客戶需求博投。
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.
譯：
技術(shù)支持這事有點(diǎn)可能違反你的直覺因?yàn)橐粋€(gè)良好的平臺(tái)按道理是不需要技術(shù)支持的。然而大部分人也同意即使是再好的產(chǎn)品也需要提供偶爾的技術(shù)支持盯蝴。
平臺(tái)的靈活性和擴(kuò)展性越好就讓技術(shù)支持這件事變得越必要毅哗。對(duì)于定制化的平臺(tái)，要是能充分利用所有特性那么提供一點(diǎn)技術(shù)支持更是必不可少捧挺。提供技術(shù)支持的方式可以通過在線聊天虑绵，在線合同和票務(wù)的形式進(jìn)行支持。
注：
一個(gè)良好的技術(shù)平臺(tái)要有一些跟客戶溝通的渠道闽烙，即使再牛逼的產(chǎn)品都必不可少翅睛。一來能讓客戶充分挖掘你平臺(tái)的產(chǎn)品特性，同時(shí)也能提供一定反饋回來指導(dǎo)和優(yōu)化平臺(tái)黑竞。實(shí)際中你可以建立一個(gè)社區(qū)或者建立一個(gè)在線聊天系統(tǒng)等都可以做好這件事捕发。
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.
譯：
一刀切或者一套標(biāo)準(zhǔn)很難奏效，因?yàn)槟愕钠脚_(tái)適應(yīng)一部分人意味著不一定另外的人很魂。
對(duì)于買了新手機(jī)的人非常熟悉一點(diǎn)扎酷，就是新設(shè)備上常常會(huì)預(yù)安裝一堆東西，這些東西非常難刪除遏匆。如果有些用戶不需要這些霞玄，你為啥讓他必須擁有這些骤铃？
相反地，有一個(gè)問題是需要某樣?xùn)|西但是你卻得不到它坷剧。無論是安全配置還是特殊功能，流媒體平臺(tái)都要提供一種解決方案喊暖，讓用戶不受任何限制地構(gòu)建自己想要的東西惫企。
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.
譯：
顯然，一個(gè)運(yùn)行良好的平臺(tái)非常重要陵叽，然而狞尔，它如何持續(xù)長時(shí)間的運(yùn)行也非常重要。正如Falsh最近衰落顯示的那樣巩掺，驅(qū)動(dòng)流媒體直播的技術(shù)是隨時(shí)可能發(fā)生變化的偏序。
在開發(fā)過程中總會(huì)出現(xiàn)新的標(biāo)準(zhǔn)，同時(shí)精簡的協(xié)議和高效的編碼器也是市場不可或缺的一部分胖替。
一個(gè)好的視頻流媒體平臺(tái)不會(huì)因?yàn)閯?chuàng)造一個(gè)產(chǎn)品就停止腳步研儒，應(yīng)該根據(jù)客戶的反饋?zhàn)龀稣{(diào)整，以便努力的改善平臺(tái)独令。
注：
打造一個(gè)好的流媒體平臺(tái)需要關(guān)注市場中出現(xiàn)的新協(xié)議端朵，新標(biāo)準(zhǔn)和高效的編解碼方案。只有不斷跟隨潮流燃箭，才能讓自己的系統(tǒng)更優(yōu)秀冲呢。
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.
譯：沒有多少功能可以彌補(bǔ)一個(gè)性能不佳的流媒體平臺(tái)。廣泛的測試和一致的性能對(duì)您的應(yīng)用程序非常重要招狸。
往期文章回顧:
基于HLS-TS&RTMP-FLV的微信小程序點(diǎn)直播方案
一圖看懂音視頻核心技術(shù)棧（框架敬拓、工具和場景））
國產(chǎn)開源流媒體SRS4.0對(duì)視頻監(jiān)控GB28181的支持
從方塊效應(yīng)&呼吸效應(yīng)看編碼量化參數(shù)對(duì)流控的作用
SDP在RTSP、國標(biāo)GB28181裙戏、WebRTC中的實(shí)踐
視頻監(jiān)控?cái)z像頭的互聯(lián)網(wǎng)化實(shí)踐思路
周末活動(dòng)回顧：視頻質(zhì)量主觀評(píng)價(jià)乘凸、實(shí)時(shí)RTC和AV1
音視頻解封裝：MP4核心Box詳解及H264&AAC打包方案
音視頻封裝格式：AAC音頻基礎(chǔ)和ADTS打包方案詳解
音視頻壓縮：H264碼流層次結(jié)構(gòu)和NALU詳解
個(gè)人轉(zhuǎn)載內(nèi)容至朋友圈和群聊天，無需特別申請(qǐng)版權(quán)許可挽懦。
引用轉(zhuǎn)載該訂閱號(hào)文章翰意，注明文章來源即可。
記得右下角點(diǎn)“在看”信柿，還可以關(guān)注該訂閱號(hào)冀偶，防止遺漏推送哦
今天就說這么多，祝您工作順利渔嚷！
如果有疑問进鸠，你可以在公眾號(hào)后臺(tái)發(fā)消息咨詢我。
