整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
動端web開發(fā)框架、類庫和UI組件簡介，有需要的收藏一波。
react-native
一個基于React的創(chuàng)建原生APP的框架
html5-boilerplate
一個用來構(gòu)建快速、強大、可適配的webapp的前端模板
ionic
領(lǐng)先的HTML5移動開發(fā)框架和SDK，利用你所熟知的web技術(shù)構(gòu)建難以置信的移動應(yīng)用，是AngularJS最好的朋友。
weui
由微信官方設(shè)計團隊為微信Web開發(fā)量身打造的框架，包含移動web應(yīng)用開發(fā)中有用的組件和模塊
hammer.js
實現(xiàn)多點觸控的javascript庫
weex
阿里推出的跨平臺的移動端開發(fā)框架，具有輕量級、可擴展和高性能的特點
fastclick
一個消除移動端瀏覽器上的點擊事件的300ms的延遲
zepto
Zepto.jsisaminimalistJavaScriptlibraryformodernbrowsers,withajQuery-compatibleAPI
vux
基于Vue和Weui的移動端框架
wepy
騰訊團隊推出的小程序組件化開發(fā)框架
NativeScript
NativeScript是一個利用JavaScript等WEB技術(shù)創(chuàng)建原生APP的框架
Framework7
功能強大的創(chuàng)建iOS&AndroidAPP的HTML框架
mui
最接近原生APP體驗的高性能框架
ratchet
用簡單的HTML,CSS,和JavaScript組件創(chuàng)建移動應(yīng)用
react-native-elements
ReactNativeUI組件庫
mint-ui
基于vue.js的移動端UI框架
amazeui
移動端優(yōu)先的開源HTML5跨屏前端框架，俗稱妹子UI
jquery-mobile
jQuery移動開發(fā)框架
Mars
騰訊移動Web前端知識庫
interact.js
JavaScriptdraganddrop,resizingandmulti-touchgestureswithinertiaandsnappingformodernbrowsers(andalsoIE8+)
vant
有贊開發(fā)的基于Vue.js2.0的UI組件庫
OnsenUI
用來構(gòu)建混合移動端APP的HTML5UI框架
muse-ui
基于Vue2.0和MaterialDesigin的UI組件庫
SUI-Mobile
SUIMobile(MSUI)是由阿里巴巴國際UED前端出品的一個手機端的UI庫，輕量精美。更多信息請參考官網(wǎng)
ant-design-mobile
一個可配置的移動端UI框架
TouchSwipe-Jquery-Plugin
TouchSwipeisajqueryplugintobeusedwithjQueryontouchinputdevicessuchasiPad,iPhoneetc.
jquery-weui
創(chuàng)建微信混合app的UI庫
jquery-ui-touch-punch
AduckpunchforaddingtoucheventstojQueryUI
device.js
Device.jsmakesiteasytowriteconditionalCSS_and/or_JavaScriptbasedondeviceoperatingsystem(iOS,Android,Blackberry,Windows,FirefoxOS,MeeGo),orientation(Portraitvs.Landscape),andtype(Tabletvs.Mobile).
react-native-ui-kitten
可定制和可重用的react-native組件包
iview-weapp
一套高質(zhì)量的微信小程序UI組件庫
vonic
基于Vue.js和ionic組件的SPAUI框架
brick
UIWebComponentsforModernWebApps
app
App.js是一個用來創(chuàng)建移動webapp的輕量級JavaScriptUI框架，可以表現(xiàn)得像原生APP而又不犧牲性能和優(yōu)雅
Lungo.js
一個給開發(fā)者提供的設(shè)計、構(gòu)建、分享跨設(shè)備應(yīng)用的框架
AlloyFinger
騰訊Web前端團隊推出的輕量級的多點觸控手勢庫
FooTable
jQueryplugintomakeHTMLtablesresponsive
vue-ydui
一個基于Vue2.x的移動端組件庫
wechat-h5-boilerplate
為騰訊微信優(yōu)化的H5動效模板，幫助你快速構(gòu)建全屏滾動型H5頁面
slip
通過滑動和拖動手勢操作列表的UI庫
mobi.css
一個關(guān)注于移動端的輕量級的、靈活的css框架，
vue-touch
Vue.js的Hammer.js包裝器
QuoJS
針對移動設(shè)備的微型JavaScript庫
pressure
:point_down::boom:JavaScriptlibraryforhandlingbothForceTouchand3DTouchontheweb
junior
一個創(chuàng)建類似原生APP的html5應(yīng)用的前端框架
vum
為手機webapp打造的基于Vue.js構(gòu)建的UI框架
mobiscroll
ThecustomizablemobileUIlibraryfortouchdeviceslikesmartphonesandtablets
zingtouch
一個JavaScript觸摸手勢檢測庫
montage
montagejs是一個優(yōu)雅的、開源的HTML5框架。它提供了模塊化組件，雙向數(shù)據(jù)綁定，以及更多功能
pushy
Pushyisaresponsiveoff-canvasnavigationmenuusingCSStransforms&transitions
GMU
基于zepto的ui組件庫，適用于移動端
flex.css
flex.cssis是一個聲明式的布局框架，能夠兼容多個MVVM框架和瀏覽器
mobilebone
單頁切換骨架。適用于移動webAPP,Hybrid混合APP,Phonegap開發(fā),無兼容要求單頁PC應(yīng)用等
jquery.pep.js
Pep,alightweightpluginforkineticdragonmobile/desktop
Cloudajs
CloudaFramework-一個針對移動WebApp的實時JavaScriptRIA框架
jo
Jo(0.5.0)是一個輕量級的(~16K)創(chuàng)建HTML5應(yīng)用的外殼。可以和PhoneGap,Chrome,Safari,Opera,FireFox,iOS,Android,BlackBerry10,Tizen,&WindowsPhone8+一起工作
touchui
高質(zhì)量移動端UI框架
iosselect
一個簡潔好看的模仿ios的webapp下拉菜單
mand-mobile
面向金融場景的Vue移動端UI組件庫，豐富、靈活、實用，快速搭建優(yōu)質(zhì)的金融類產(chǎn)品
tabris-js
tabris.js-用JavaScript開發(fā)原生應(yīng)用
aui
移動端UI快速布局解決方案（APICloudUI框架）
vue-carbon
基于vue開發(fā)的materialdesignui庫
cordova-plugin-ibeacon
AniBeaconpluginforPhonegap/Cordova3.xandupwards.SupportsbothiOSandAndroid(contributionsarewelcome)
touch.code.baidu.com
TouchOfficalSite
bindingx
阿里團隊推出的weex和ReactNative上富交互問題的一種解決方案
jQuery-Touch-Events
AcollectionofmobileeventpluginsforjQuery.
TinyNav.js
Responsivenavigationpluginthatweighsjust443bytes
Jingle
JingleUI是一個基于html5、css3開發(fā)輕量級的移動webapp框架，提供一些基本交互方式，幫助您更方便的開發(fā)移動應(yīng)用。
light7
一個輕量級的易用的移動端UI框架
framework7-vue
基于Framework7和Vue構(gòu)建iOS和Android應(yīng)用
ydui
一只注重審美，且性能高效的移動端&微信UI
slip.js
移動端跟隨手指滑動組件，零依賴。
wepayui
微信支付場景化組件，wepayui源碼
BlendUI
BlendUI是Clouda+中的重要組成部分，他能讓webapp的用戶界面體驗和交互能和Native媲美
toucher
面向移動端的手勢類庫
touchjs
一個移動端手勢檢測庫
thumbs.js
Addtouchsupporttoyourbrowserwiththumbs.js-asmall,transparent,andsyntax-lesslibrary.
JMUI
移動Web開發(fā)UI組件庫
JM
面向Mobile的極致JavaScript庫
react-ui
為React打造的一套ionic風(fēng)格的可復(fù)用UI組件庫
Zoomage.js
Zoomage.js-一個通過手勢縮放圖片的庫
touchSlider
TouchSliderjQueryPlugin
WebRTC，名稱源自網(wǎng)頁實時通信（Web Real-Time Communication）的縮寫，是一個支持網(wǎng)頁瀏覽器進行實時語音通話或視頻聊天的技術(shù)，是谷歌2010年以6820萬美元收購Global IP Solutions公司而獲得的一項技術(shù)。
WebRTC提供了實時音視頻的核心技術(shù)，包括音視頻的采集、編解碼、網(wǎng)絡(luò)傳輸、顯示等功能，并且還支持跨平臺：windows，linux，mac，android。
雖然WebRTC的目標(biāo)是實現(xiàn)跨平臺的Web端實時音視頻通訊，但因為核心層代碼的Native、高品質(zhì)和內(nèi)聚性，開發(fā)者很容易進行除Web平臺外的移殖和應(yīng)用。很長一段時間內(nèi)WebRTC是業(yè)界能免費得到的唯一高品質(zhì)實時音視頻通訊技術(shù)。
WebRTC（Web Real-Time Communication）項目的最終目的主要是讓W(xué)eb開發(fā)者能夠基于瀏覽器（Chrome\FireFox\…）輕易快捷開發(fā)出豐富的實時多媒體應(yīng)用，而無需下載安裝任何插件，Web開發(fā)者也無需關(guān)注多媒體的數(shù)字信號處理過程，只需編寫簡單的Javascript程序即可實現(xiàn)。
W3C等組織正在制定Javascript 標(biāo)準(zhǔn)API，目前是WebRTC 1.0版本、Draft狀態(tài)。
另外WebRTC還希望能夠建立一個多互聯(lián)網(wǎng)瀏覽器間健壯的實時通信的平臺，形成開發(fā)者與瀏覽器廠商良好的生態(tài)環(huán)境。同時，Google也希望和致力于讓W(xué)ebRTC的技術(shù)成為HTML5標(biāo)準(zhǔn)之一，可見Google布局之深遠。
架構(gòu)圖顏色標(biāo)識說明：
官方給出的平臺支持情況：
Web開發(fā)者開發(fā)的程序，Web開發(fā)者可以基于集成WebRTC的瀏覽器提供的web API開發(fā)基于視頻、音頻的實時通信應(yīng)用。
面向第三方開發(fā)者的WebRTC標(biāo)準(zhǔn)API（Javascript），使開發(fā)者能夠容易地開發(fā)出類似于網(wǎng)絡(luò)視頻聊天的web應(yīng)用，最新的標(biāo)準(zhǔn)化進程可以查看這里。
本地C++ API層，使瀏覽器廠商容易實現(xiàn)WebRTC標(biāo)準(zhǔn)的Web API，抽象地對數(shù)字信號過程進行處理。
傳輸/會話層：會話層組件采用了libjingle庫的部分組件實現(xiàn)，無須使用xmpp/jingle協(xié)議。
- a. RTP Stack協(xié)議棧：Real Time Protocol；
- b. STUN/ICE：可以通過STUN和ICE組件來建立不同類型網(wǎng)絡(luò)間的呼叫連接；
- c. Session Management：一個抽象的會話層，提供會話建立和管理功能。該層協(xié)議留給應(yīng)用開發(fā)者自定義實現(xiàn)。
官方給出的WebRTC STUN原理圖：
官方給出的WebRTC P2P數(shù)據(jù)收發(fā)原理圖：
音頻引擎是包含一系列音頻多媒體處理的框架，包括從視頻采集卡到網(wǎng)絡(luò)傳輸端等整個解決方案。
VoiceEngine是WebRTC極具價值的技術(shù)之一，是Google收購GIPS公司后開源的。在VoIP上，技術(shù)業(yè)界領(lǐng)先。
a. iSAC
Internet Speech Audio Codec：針對VoIP和音頻流的寬帶和超寬帶音頻編解碼器，是WebRTC音頻引擎的默認(rèn)的編解碼器。
b. iLBC
Internet Low Bitrate Codec：VoIP音頻流的窄帶語音編解碼器。標(biāo)準(zhǔn)由IETF RFC3951和RFC3952定義。
c. NetEQ for Voice
針對音頻軟件實現(xiàn)的語音信號處理元件。NetEQ算法：自適應(yīng)抖動控制算法以及語音包丟失隱藏算法。使其能夠快速且高解析度地適應(yīng)不斷變化的網(wǎng)絡(luò)環(huán)境，確保音質(zhì)優(yōu)美且緩沖延遲最小。是GIPS公司獨步天下的技術(shù)，能夠有效的處理由于網(wǎng)絡(luò)抖動和語音包丟失時候?qū)φZ音質(zhì)量產(chǎn)生的影響。
NetEQ 也是WebRTC中一個極具價值的技術(shù)，對于提高VoIP質(zhì)量有明顯效果，加以AEC\NR\AGC等模塊集成使用，效果更好。
d. Acoustic Echo Canceler (AEC)
回聲消除器是一個基于軟件的信號處理元件，能實時的去除mic采集到的回聲。
e. Noise Reduction (NR)
噪聲抑制也是一個基于軟件的信號處理元件，用于消除與相關(guān)VoIP的某些類型的背景噪聲（嘶嘶聲，風(fēng)扇噪音等等… …）
WebRTC視頻處理引擎：VideoEngine是包含一系列視頻處理的整體框架，從攝像頭采集視頻到視頻信息網(wǎng)絡(luò)傳輸再到視頻顯示整個完整過程的解決方案。
a. VP8
視頻圖像編解碼器，是WebRTC視頻引擎的默認(rèn)的編解碼器。VP8適合實時通信應(yīng)用場景，因為它主要是針對低延時而設(shè)計的編解碼器。
VPx編解碼器是Google收購ON2公司后開源的，VPx現(xiàn)在是WebM項目的一部分，而WebM項目是Google致力于推動的HTML5標(biāo)準(zhǔn)之一。
b. Video Jitter Buffer
視頻抖動緩沖器，可以降低由于視頻抖動和視頻信息包丟失帶來的不良影響。
c. Image enhancements
圖像質(zhì)量增強模塊：對網(wǎng)絡(luò)攝像頭采集到的圖像進行處理，包括明暗度檢測、顏色增強、降噪處理等功能，用來提升視頻質(zhì)量。
附：webrtc學(xué)習(xí)視頻教程
目的：幫助更多的學(xué)員入門WebRTC，視頻免費領(lǐng)取，后臺私信 1
分為以下章節(jié)：
（1）WebRTC入門
（2）WebRTC開發(fā)環(huán)境搭建
（3）Coturn穿透和轉(zhuǎn)發(fā)服務(wù)器搭建
（4）音視頻采集和播放
（5）Nodejs實戰(zhàn)
（6）手把手實現(xiàn)音視頻一對一通話（包含信令協(xié)議設(shè)計、Web to Web、Android to Web、 Android to Android）
（7）開源方案介紹
（8）AppRTC開源方案搭建
另外關(guān)于c++ Linux后臺服務(wù)器開發(fā)的一些知識點分享：Linux，Nginx，MySQL，Redis，P2P，K8S，Docker，TCP/IP，協(xié)程，DPDK，webrtc，音視頻等等視頻。
喜歡的朋友可以后臺私信【1】獲取學(xué)習(xí)視頻
最原始的直播系統(tǒng)其實并沒有想象的那么復(fù)雜，無非就是主播端將音視頻數(shù)據(jù)推送到服務(wù)器，觀眾端則從服務(wù)器拉取數(shù)據(jù)播放。
推流，是直播中的一個術(shù)語，意思是將流媒體數(shù)據(jù)推送到服務(wù)器。如何推流，關(guān)鍵就在于使用的推流協(xié)議。
拉流，指的是觀眾端流媒體數(shù)據(jù)的拉取，同樣也需要通過約定的拉流協(xié)議來拉取。
幀，是視頻的一個基本概念，表示一張畫面，如上面的翻頁動畫書中的一頁，就是一幀。一個視頻就是由許許多多幀組成的。
幀率，即單位時間內(nèi)幀的數(shù)量，單位為：幀/秒 或fps（frames per second）。如動畫書中，一秒內(nèi)包含多少張圖片，圖片越多，畫面越順滑，過渡越自然。幀率的一般以下幾個典型值：
這里我們只講常用到的兩種色彩空間。
RGB的顏色模式應(yīng)該是我們最熟悉的一種，在現(xiàn)在的電子設(shè)備中應(yīng)用廣泛。通過R G B三種基礎(chǔ)色，可以混合出所有的顏色。
YUV是一種亮度與色度分離的色彩格式。早期的電視都是黑白的，即只有亮度值，即Y。有了彩色電視以后，加入了UV兩種色度，形成現(xiàn)在的YUV，也叫YCbCr。Y：亮度，就是灰度值。除了表示亮度信號外，還含有較多的綠色通道量。U：藍色通道與亮度的差值。V：紅色通道與亮度的差值。
因為人眼對亮度敏感，對色度不敏感，因此減少部分UV的數(shù)據(jù)量，人眼卻無法感知出來，這樣可以通過壓縮UV的分辨率，在不影響觀感的前提下，減小視頻的體積。
采樣率即采樣的頻率。采樣率要大于原聲波頻率的2倍，人耳能聽到的最高頻率為20kHz，所以為了滿足人耳的聽覺要求，采樣率至少為40kHz，通常為44.1kHz，更高的通常為48kHz。
采樣位數(shù)涉及到聲波的振幅量化。波形振幅在模擬信號上也是連續(xù)的樣本值，而在數(shù)字信號中，信號一般是不連續(xù)的，所以模擬信號量化以后，只能取一個近似的整數(shù)值，為了記錄這些振幅值，采樣器會采用一個固定的位數(shù)來記錄這些振幅值，通常有8位、16位、32位。位數(shù)越多，記錄的值越準(zhǔn)確，還原度越高。由于數(shù)字信號是由0，1組成的，因此，需要將幅度值轉(zhuǎn)換為一系列0和1進行存儲，也就是編碼，最后得到的數(shù)據(jù)就是數(shù)字信號：一串0和1組成的數(shù)據(jù)。
聲道數(shù)，是指支持能不同發(fā)聲（注意是不同聲音）的音響的個數(shù)。單聲道：1個聲道雙聲道：2個聲道立體聲道：默認(rèn)為2個聲道立體聲道（4聲道）：4個聲道
碼率，是指一個數(shù)據(jù)流中每秒鐘能通過的信息量，單位bps（bit per second）碼率 = 采樣率 * 采樣位數(shù) * 聲道數(shù)
編碼可以大大減小音視頻數(shù)據(jù)的大小，讓音視頻更容易存儲和傳送。視頻編碼格式有很多，比如H26x系列和MPEG系列的編碼，這些編碼格式都是為了適應(yīng)時代發(fā)展而出現(xiàn)的。其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）國際電傳視訊聯(lián)盟主導(dǎo)。MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的組織）主導(dǎo)。
原始的PCM音頻數(shù)據(jù)也是非常大的數(shù)據(jù)量，因此也需要對其進行壓縮編碼。和視頻編碼一樣，音頻也有許多的編碼格式，如：WAV、MP3、WMA、APE、FLAC等等。在MP4視頻中的音頻數(shù)據(jù)，大多數(shù)時候都是采用AAC壓縮格式。AAC是新一代的音頻有損壓縮技術(shù)，一種高壓縮比的音頻壓縮算法。
我們熟悉的視頻格式，如mp4、rmvb、avi、mkv、mov...，其實是包裹了音視頻編碼數(shù)據(jù)的容器，用來把以特定編碼標(biāo)準(zhǔn)編碼的視頻流和音頻流混在一起，成為一個文件。例如：mp4支持H264、H265等視頻編碼和AAC、MP3等音頻編碼。
在手機或者PC上，都會有CPU、GPU或者解碼器等硬件。通常，我們的計算都是在CPU上進行的，也就是我們軟件的執(zhí)行芯片，而GPU主要負責(zé)畫面的顯示（是一種硬件加速）。
所謂軟解碼，就是指利用CPU的計算能力來解碼，通常如果CPU的能力不是很強的時候，一則解碼速度會比較慢，二則手機可能出現(xiàn)發(fā)熱現(xiàn)象。但是，由于使用統(tǒng)一的算法，兼容性會很好。
硬解碼，指的是利用手機上專門的解碼芯片來加速解碼。通常硬解碼的解碼速度會快很多，但是由于硬解碼由各個廠家實現(xiàn)，質(zhì)量參差不齊，非常容易出現(xiàn)兼容性問題。
通過下面這個數(shù)據(jù)流程圖，能清晰地看到整個直播的過程。
可以看到，主播客戶端 處理的事情，其實就是短視頻開發(fā)中最重要的內(nèi)容：
流程詳細操作音視頻數(shù)據(jù)采集通過攝像頭和麥克風(fēng)采集音視頻濾鏡通過 OpenGL 和 SoundTouch 等工具實現(xiàn)音視頻編輯音視頻編碼通過系統(tǒng)硬編碼 或 FFmpeg 軟編碼，將數(shù)據(jù)編碼為 H264 和 AAC數(shù)據(jù)封裝打包將編碼好的數(shù)據(jù)封裝成指定的格式
唯一不一樣的地方，短視頻會將封裝好的數(shù)據(jù)保存到本地，直播則是通過 推流協(xié)議 將數(shù)據(jù)推送到服務(wù)器。
在直播中，有幾個非常重要的地方，會直接影響直播效果，導(dǎo)致用戶流失。
首屏?xí)r間，即從觀眾打開直播，到看到畫面呈現(xiàn)出來的時間。影響這個時間的是 H264 編碼中的一個概念： GOP 。GOP：Group of Picture，即一組幀組成的一個序列。在 H264 中，分別有 I幀、P幀、B幀 三種幀類型。GOP 就是由一個 I幀 和多個 P幀 或 B幀 組成的一組相近的畫面 。
在H264中，三種類型的幀數(shù)據(jù)分別為I幀：幀內(nèi)編碼幀。就是一個完整幀。P幀：前向預(yù)測編碼幀。是一個非完整幀，通過參考前面的I幀或P幀生成。B幀：雙向預(yù)測內(nèi)插編碼幀。參考前后圖像幀編碼生成。B幀依賴其前最近的一個I幀或P幀及其后最近的一個P幀。
解碼器可以直接解碼I幀 ，但是P幀和B幀必須依賴I幀，或者前后的P或B才能解碼。首次連上直播間時，需要拋棄掉P和B幀，等待I幀。所以，影響首屏?xí)r間最重要的因素就是I幀，也就是兩個GOP之間的間隔時間。
GOP 間隔的設(shè)置并非越小越好，太小則兩個I幀之間的P/B幀越少，壓縮率越低，畫面質(zhì)量越差，需要做好權(quán)衡。
我們知道網(wǎng)絡(luò)是不穩(wěn)定的，經(jīng)常會出現(xiàn)網(wǎng)速慢，甚至斷網(wǎng)的問題，所以穩(wěn)定性優(yōu)化也是非常重要的。 比如以下幾個方面：
同樣分辨率下，碼率越高，視頻越清晰，同時需要的帶寬也越大。相反，碼率越低，視頻越模糊，數(shù)據(jù)越小。
根據(jù)不同的網(wǎng)速切換不同的碼率進行播放等。
網(wǎng)絡(luò)斷開時的重聯(lián)機制。
隨著業(yè)務(wù)的發(fā)展，如果主播和觀眾的數(shù)量越來越多以后，系統(tǒng)可能會面臨高并發(fā)情景，直播卡頓，甚至系統(tǒng)奔潰，解決這種情況的一個好辦法就是使用 CDN 。
CDN內(nèi)容分發(fā) 解決因分布、帶寬、服務(wù)器性能帶來的訪問延遲問題，適用于站點加速、點播、直播。
加入 CDN 后，整個直播系統(tǒng)架構(gòu)如下：
除了以上提到的內(nèi)容，當(dāng)今的直播系統(tǒng)還要包括以下內(nèi)容：錄制、轉(zhuǎn)碼、鑒黃、截屏、權(quán)鑒防盜、回聲消除、連麥 等等，整套下來，需要非常多的知識儲備，以及大量的時間精力，才能完成。
直播協(xié)議包含了上面提到的 推流 和 拉流 協(xié)議。
實時傳輸協(xié)議（Real-time Transport Protocol，縮寫RTP）是一個網(wǎng)絡(luò)傳輸協(xié)議，它是由IETF的多媒體傳輸工作小組1996年在RFC 1889中公布的。
RTP協(xié)議詳細說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標(biāo)準(zhǔn)數(shù)據(jù)包格式。它一開始被設(shè)計為一個多播協(xié)議，但后來被用在很多單播應(yīng)用中。RTP協(xié)議常用于流媒體系統(tǒng)（配合RTSP協(xié)議），視頻會議和一鍵通（Push to Talk）系統(tǒng)（配合H.323或SIP），使它成為IP電話產(chǎn)業(yè)的技術(shù)基礎(chǔ)。RTP協(xié)議和RTP控制協(xié)議RTCP一起使用，而且它是創(chuàng)建在UDP協(xié)議上的。
實時消息協(xié)議（Real-Time Messaging Protocol，縮寫RTMP）也稱實時消息傳輸協(xié)議，是最初由Macromedia為通過互聯(lián)網(wǎng)在Flash播放器與一個服務(wù)器之間傳輸流媒體音頻、視頻和數(shù)據(jù)而開發(fā)的一個專有協(xié)議。Macromedia后被Adobe Systems收購，該協(xié)議也已發(fā)布了不完整的規(guī)范供公眾使用。
RTMP協(xié)議有許多變種：
WebRTC是一個由谷歌、Mozilla和Opera等支持的開源技術(shù)。它通過簡單的api為瀏覽器和移動應(yīng)用程序提供實時通信(RTC)功能。為瀏覽器、移動平臺和物聯(lián)網(wǎng)設(shè)備開發(fā)豐富、高質(zhì)量的RTC應(yīng)用程序，并允許它們通過一組通用協(xié)議進行通信。支持的瀏覽器和平臺：
特點：
HTTP Live Streaming（縮寫是HLS）是一個由蘋果公司提出的基于HTTP的流媒體網(wǎng)絡(luò)傳輸協(xié)議。它的工作原理是把整個流分成一個個小的基于HTTP的文件來下載，每次只下載一些。當(dāng)媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應(yīng)不同的數(shù)據(jù)速率。在開始一個流媒體會話時，客戶端會下載一個包含元數(shù)據(jù)的extended M3U (m3u8) playlist文件，用于尋找可用的媒體流。HLS只請求基本的HTTP報文，與實時傳輸協(xié)議（RTP）不同，HLS可以穿過任何允許HTTP數(shù)據(jù)通過的防火墻或者代理服務(wù)器。它也很容易使用內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）來傳輸媒體流。
目前 WebRTC 提供了在 Web、iOS、Android、Mac、Windows、Linux 在內(nèi)的所有平臺的 API，保證了 API 在所有平臺的一致性。使用 WebRTC 的好處主要有以下幾個方面：
P2P(peer to peer)對等通信。 即在p2p的網(wǎng)絡(luò)中，所有網(wǎng)絡(luò)節(jié)點都是同等地位，沒有服務(wù)端和客戶端之分，一個節(jié)點即是服務(wù)端也是客戶端。客戶端之間可以進行直接的通信，不需要在經(jīng)過服務(wù)端的中轉(zhuǎn)，從而提高網(wǎng)絡(luò)傳輸速度和減小服務(wù)器壓力，這是非常有用的。P2P雖然通信模式非常理想，但是有一些問題需要解決：
解決方案：
事實上，大部分的節(jié)點都處于常規(guī)網(wǎng)絡(luò)的邊緣，甚至在DNS所能查詢的范圍之外，所以在處于網(wǎng)絡(luò)的邊緣的節(jié)點不能直接通信的。
為了能讓客戶端在不同的網(wǎng)絡(luò)之間通信，我們就需要穿過防火墻，而且我們還要面對ISP所設(shè)置的種種限制。所以為了繞開這些限制，以及在接收端的防火墻上打開一個口讓媒體通過，我們就需要依賴STUN/TURN服務(wù)器，目的是找到一條正確的路徑（STUN），或者是作為一個中繼服務(wù)器用來傳輸媒體（TURN）
上圖中的Relay server即為TURN中繼服務(wù)器，而STUN server的作用是通過收集NAT背后peer端(即：躲在路由器或交換機后的電腦）對外暴露出來的ip和端口，找到一條可穿透路由器的鏈路，俗稱“打洞”。STUN/TURN服務(wù)器通常要部署在公網(wǎng)上，能被所有peer端訪問到。
WebRTC被認(rèn)為是一種點對點技術(shù)，瀏覽器可以直接通信而無需任何類型的基礎(chǔ)設(shè)施。此模型足以創(chuàng)建基本應(yīng)用程序，但難以在其之上實現(xiàn)諸如組通信，媒體流記錄，媒體廣播或媒體轉(zhuǎn)碼之類的功能。因此，許多應(yīng)用程序都需要使用媒體服務(wù)器。
從概念上講，WebRTC媒體服務(wù)器只是一種“多媒體中間件”，從源到目的地時，媒體流量會通過該中間件。媒體服務(wù)器能夠處理媒體流并提供不同的類型，包括組通信（將一個對等方生成的媒體流分配給多個接收方，即充當(dāng)多會議單元，MCU），混合（將多個傳入流轉(zhuǎn)換為一個單一的復(fù)合流） ，轉(zhuǎn)碼（在不兼容的客戶端之間適應(yīng)編解碼器和格式），錄制（以持久的方式存儲對等體之間交換的媒體）等。媒體服務(wù)器的好處有如下幾點：
當(dāng)媒體服務(wù)器充當(dāng)媒體中繼時，它通常被稱為SFU（Selective Forwarding Unit選擇性轉(zhuǎn)發(fā)單位），這意味著其主要目的是在客戶端之間轉(zhuǎn)發(fā)媒體流。還有一個MCU（Multipoint Conferencing Unit多點會議單元）的概念，MCU服務(wù)器不僅可以轉(zhuǎn)發(fā)，而且可以對媒體流進行混合和編碼壓縮（比如把各個客戶端的數(shù)據(jù)打包轉(zhuǎn)發(fā)，和SFU相比，這樣將大幅度降低轉(zhuǎn)發(fā)數(shù)據(jù)的帶寬需求，但對CPU有更高的要求）。
每個端都與其它端互連。以上圖最左側(cè)為例，5個瀏覽器，二二建立p2p連接，每個瀏覽器與其它4個建立連接，總共需要10個連接。如果每條連接占用1m帶寬，則每個端上行需要4m，下行帶寬也要4m，總共帶寬消耗20m。而且除了帶寬問題，每個瀏覽器上還要有音視頻“編碼/解碼”，cpu使用率也是問題，一般這種架構(gòu)只能支持4-6人左右，不過優(yōu)點也很明顯，沒有中心節(jié)點，實現(xiàn)很簡單。
優(yōu)點：
缺點：
這是一種傳統(tǒng)的中心化架構(gòu)(上圖中間部分)，每個瀏覽器僅與中心的MCU服務(wù)器連接，MCU服務(wù)器負責(zé)所有的視頻編碼、轉(zhuǎn)碼、解碼、混合等復(fù)雜邏輯，每個瀏覽器只要1個連接，整個應(yīng)用僅消耗5個連接，帶寬占用(包括上行、下行）共10m，瀏覽器端的壓力要小很多，可以支持更多的人同時音視頻通訊，比較適合多人視頻會議。但是MCU服務(wù)器的壓力較大，需要較高的配置。
以前在電信行業(yè)做視頻會議一般都使用MCU(Multipoint Control Unit)，也就是多方推流在MCU上進行合流，在拉流的時候只有一路合流，這樣的好處是無論幾方推流，拉流只有一路，下行帶寬比較小。但是問題也比較多，只要推流方一多，MCU的壓力就比較大，而且分布式的部署也比較難，成本又很高。
上圖右側(cè)部分，咋一看，跟MCU好象沒什么區(qū)別，但是思路不同，仍然有中心節(jié)點服務(wù)器，但是中心節(jié)點只負責(zé)轉(zhuǎn)發(fā)，不做太重的處理，所以服務(wù)器的壓力會低很多，配置也不象MUC要求那么高。但是每個端需要建立一個連接用于上傳自己的視頻，同時還要有N-1個連接用于下載其它參與方的視頻信息。所以總連接數(shù)為5*5，消耗的帶寬也是最大的，如果每個連接1M帶寬，總共需要25M帶寬，它的典型場景是1對N的視頻互動。SFU 服務(wù)器最核心的特點是把自己 “偽裝” 成了一個 WebRTC 的 Peer 客戶端，WebRTC 的其他客戶端其實并不知道自己通過 P2P 連接過去的是一臺真實的客戶端還是一臺服務(wù)器，我們通常把這種連接稱之為 P2S，即：Peer to Server。除了 “偽裝” 成一個 WebRTC 的 Peer 客戶端外，SFU 服務(wù)器還有一個最重要的能力就是具備 one-to-many 的能力，即可以將一個 Client 端的數(shù)據(jù)轉(zhuǎn)發(fā)到其他多個 Client 端。
這種網(wǎng)絡(luò)拓撲結(jié)構(gòu)中，無論多少人同時進行視頻通話，每個 WebRTC 的客戶端只需要連接一個 SFU 服務(wù)器，上行一路數(shù)據(jù)即可，極大減少了多人視頻通話場景下 Mesh 模型給客戶端帶來的上行帶寬壓力。
SFU 服務(wù)器跟 TURN 服務(wù)器最大的不同是，TURN 服務(wù)器僅僅是為 WebRTC 客戶端提供的一種輔助的數(shù)據(jù)轉(zhuǎn)發(fā)通道，在 P2P 不通的時候進行透明的數(shù)據(jù)轉(zhuǎn)發(fā)。而 SFU 是 “懂業(yè)務(wù)” 的， 它跟 WebRTC 客戶端是平等的關(guān)系，甚至 “接管了” WebRTC 客戶端的數(shù)據(jù)轉(zhuǎn)發(fā)的申請和控制。
現(xiàn)在互聯(lián)網(wǎng)行業(yè)比較流行的是SFU(Selective Forwarding Unit)，簡單說就是只負責(zé)轉(zhuǎn)發(fā)流，不負責(zé)合流，壓力很小。這樣的模式可以依托CDN進行分布式的部署，不過拉流的方數(shù)限于客戶端的帶寬和處理能力。
純 mesh 方案無法適應(yīng)多人視頻通話，也無法實現(xiàn)服務(wù)端的各種視頻處理需求，最先排除在商業(yè)應(yīng)用之外。
SFU 相比于 MCU，服務(wù)器的壓力更小（純轉(zhuǎn)發(fā)，無轉(zhuǎn)碼合流），靈活性更好（可選擇性開關(guān)任意一路數(shù)據(jù)的上下行等），受到更廣泛的歡迎和應(yīng)用，常見的開源 SFU 服務(wù)器有：Licode，Kurento，Janus，Jitsi，Mediasoup等。
當(dāng)然，也可以組合使用 SFU + MCU 的混合方案，以靈活應(yīng)對不同場景的應(yīng)用需要。
很多成功的、被良好維護的開源項目背后都有一個商業(yè)模式，尤其是中小型的項目，這意味著有一個團隊以此為謀生手段。具備可選的付費支持意味著：
* 有人愿意全職來改善這東西，而不是作為愛好來維護。
* 如果你需要緊急幫助，只要花錢就能得到。
https://github.com/jitsi/jitsiJitsi是一個免費的開源音頻/視頻和聊天通信器，它支持SIP、XMPP/Jabber、AIM/ICQ、IRC和許多其他有用的特性。
Jitsi不僅是WebRTC媒體服務(wù)器，而且還有一個完整的平臺。 Jitsi系列產(chǎn)品包括Jitsi Videobridge（媒體中繼，SFU），Jitsi Meet（會議網(wǎng)絡(luò)客戶端），Jicofo（Jitsi Conference Focus），Jigasi（Jitsi Gateway to SIP）和Jitsi SIP Phone。借助Jitsi我們能在幾個小時之內(nèi)迅速搭建一個完整可用的通信平臺。 它還使用Jingle（XMPP）和功能齊全的Web界面實現(xiàn)自己的信令控制。 然而，令人遺憾的是，它對于媒體錄制沒有提供穩(wěn)定易用的解決方案。
https://github.com/Kurento/kurento-media-serverKurento是WebRTC媒體服務(wù)器和一組客戶端API，可簡化針對WWW和智能手機平臺的高級視頻應(yīng)用程序的開發(fā)。Kurento Media Server的功能包括組通信，音視頻流的轉(zhuǎn)碼，記錄，混合，廣播和路由。
作為一項與眾不同的功能，Kurento Media Server還提供了高級媒體處理功能，包括計算機視覺，視頻索引，增強現(xiàn)實和語音分析。Kurento模塊化體系結(jié)構(gòu)簡化了第三方媒體處理算法（即語音識別，情感分析，面部識別等）的集成，可以由應(yīng)用程序開發(fā)人員透明地用作Kurento的其余內(nèi)置功能。
Kurento Media Server通過稱為Kurento API的RPC API公開其所有功能。可以通過任何與JSON兼容的客戶端直接查詢該API，但是推薦的使用方法是通過Kurento客戶端庫。目前為Java，Browser Javascript和Node.js提供了這些工具。
如果您喜歡其他編程語言，則可以遵循基于WebSocket和JSON-RPC的Kurento協(xié)議的規(guī)范來編寫自定義客戶端庫。
Kurento被設(shè)計為可插入框架，Kurento中的每個插件都稱為一個模塊，可以使用新的自定義模塊擴展Kurento Media Server。更多信息，請閱讀Kurento模塊部分。
Kurento模塊分為三類：
與Kurento Media Server開箱即用合并：
Kurento團隊開發(fā)的額外模塊，用于增強Kurento Media Server的基本功能。到目前為止，有四個內(nèi)置模塊，分別是：
Kurento Media Server的擴展，提供了新的媒體功能。
https://github.com/lynckia/licodeLicode基于WebRTC技術(shù)。它與Google Chrome的最新穩(wěn)定版本100％兼容。您的用戶將無需安裝任何內(nèi)容即可通過其Web瀏覽器進行交談。無需關(guān)心復(fù)雜的實時基礎(chǔ)架構(gòu)。它提供了基于HTML5的視頻會議功能的快速開發(fā)，使它100％可擴展。Licode允許您在網(wǎng)絡(luò)上包括電視會議室。但是您也可以實現(xiàn)流媒體，錄制和您夢dream以求的任何其他實時多媒體功能！
主要模塊及實現(xiàn)語言：
https://github.com/meetecho/janus-gateway
Janus是由Meetecho開發(fā)的WebRTC服務(wù)器，被認(rèn)為是通用服務(wù)器。因此，除了實現(xiàn)與瀏覽器建立WebRTC媒體通信，與之交換JSON消息以及在瀏覽器與服務(wù)器端應(yīng)用程序邏輯之間中繼RTP / RTCP和消息的手段之外，它本身不提供任何功能。服務(wù)器端插件提供了任何特定的功能/應(yīng)用程序，然后瀏覽器可以通過Janus與之聯(lián)系，以利用它們提供的功能。此類插件的示例可以是諸如回聲測試，會議橋，媒體記錄器，SIP網(wǎng)關(guān)等應(yīng)用程序的實現(xiàn)。
這樣做的原因很簡單：我們想要的東西將具有 small footprint（因此是C實現(xiàn)），并且只能配備以前的東西really needed（因此可插入模塊）。就是說，這使我們能夠在云上部署成熟的WebRTC網(wǎng)關(guān)，或者使用小型的nettop / box來處理特定的用例。
其最顯著的特征之一是其插件架構(gòu)，可以增強服務(wù)的核心功能。有一些有趣的Janus用例，例如SIP Gateway，屏幕共享等。
https://github.com/versatica/mediasoup由于其多功能性，性能和可伸縮性，mediasoup成為構(gòu)建多方視頻會議和實時流應(yīng)用程序的理想選擇。它具有聯(lián)播，SVC，傳輸BWE和其他更多先進功能。
除了創(chuàng)建另一個自帶服務(wù)器之外，mediasoup是一個Node.js模塊，可以將其集成到更大的應(yīng)用程序中。mediasoup提供了一個低級API，該API支持您的應(yīng)用程序使用不同的用例。
mediasoup帶有mediasoup-client（JavaScript庫）和libmediasoupclient（C ++庫），用于構(gòu)建使用統(tǒng)一API在任何瀏覽器或設(shè)備中運行的應(yīng)用程序。或者只使用知名軟件，例如FFmpeg或GStreamer。
設(shè)計目標(biāo)mediasoup及其客戶端庫旨在實現(xiàn)以下目標(biāo)：
架構(gòu)
特征
它與其他媒體服務(wù)器的不同之處在于它被設(shè)計成一個用于Node的開發(fā)庫，這允許它可以被容易的集成到更大的應(yīng)用程序中。
*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
