webrtc伺服器搭建播放rtsp
1. 除了WebRtc還有什麼方法讀攝像頭
通過流媒體RTSP方式。除了WebRtc還能通過流媒體RTSP方式來讀攝像頭，按照不同廠家的RTSP流媒體地址格式連接即可。
2. ue4推流webrtc無法自動播放
修改cef3源碼，改成支持h264，重新編譯，然後在UE4安裝目錄下替換相關文件（csdn里能搜索到編譯好的win64版本）。【點擊免費試用，0成本啟動】
UE4引擎是需要安裝本地exe客戶端，而且為了程序能正常運行，對於電腦硬體有配置要求。而使用UE4引擎做出來的場景內容，如果想觀看是需要在其客戶端中打開。雲渲染技術和UE4場景內容的結合點是，無需將客戶端安裝在本地電腦，而是將其放在雲端伺服器，然後形成一個URL的鏈接，在終端（電腦、平板、手機、智能電視）通過這個URL鏈接直接可以操作雲端的UE客戶端，而且電腦終端的性能參數也沒有特殊的要求，因為所有的指令和渲染工作都是在雲端伺服器完成的，終端只是交互操作指令的接收、傳輸和展示。
想要了解更多關於webrtc的相關信息，推薦咨詢ZEGO即構科技。即構科技有限公司是為開發者提供高品質實時音視頻、實時語音、互動直播和IM即時通訊等服務的公司。核心團隊成員均來自QQ，有超過20年的互聯網和音視頻技術開發經驗，以及億量級海內外用戶運營服務能力。專注於實時音視頻領域，致力提供全世界范圍內最清晰穩定實時的語音視頻服務，已服務4000+企業，適用於游戲、娛樂社交、在線教育、在線醫療、遠程會議、智能硬體等多種用戶場景。
3. 如何利用webrtc端快速搭建直播框架
這個問題可以這樣回答!
4. 基於chrome的webrtc在web端能不能實現解析度動態調整，迴音消除等等
可以的，webrtc噪音迴音問題消除步驟如下：【點擊免費試用，0成本啟動】
方法/步驟
1 ，右擊桌面右下角的「喇叭」圖標，點擊「錄音設備」。
2 ，這是出現一個「麥克風」設備，右擊「麥克風」，點擊「屬性」。
3 ，「麥克風屬性」在「偵聽」中，找到「偵聽此設備」，若打鉤，把鉤去掉
4 ，再點擊「級別」，把「麥克風加強」調為0.0dB。
可以適度調節麥克風音量。
5 ，在「增強」中，選擇「禁用所有聲音效果」。
6 ，最後再在「高級」中，找到「獨占模式」，在它下邊有兩個選項，全部打鉤。
分別是「允許應用程序獨占控制該設備」「給與獨占模式應用程序優先」。還可以調下「默認格式」。
想要了解更多關於webrtc 的信息，推薦咨詢ZEGO即構科技。即構科技有限公司是為開發者提供高品質實時音視頻、實時語音、互動直播和IM即時通訊等服務的公司。核心團隊成員均來自QQ，有超過20年的互聯網和音視頻技術開發經驗，以及億量級海內外用戶運營服務能力。專注於實時音視頻領域，致力提供全世界范圍內最清晰穩定實時的語音視頻服務，已服務4000+企業，適用於游戲、娛樂社交、在線教育、在線醫療、遠程會議、智能硬體等多種用戶場景。
5. webrtc伺服器需要多少帶寬
webrtc中的帶寬自適應演算法分為兩種：
1，發端帶寬控制，原理是由rtcp中的丟包統計來動態的增加或減少帶寬，在減少帶寬時使用TFRC演算法來增加平滑度。
2，收端帶寬估算，原理是並由收到rtp數據，估出帶寬；用卡爾曼濾波，對每一幀的發送時間和接收時間進行分析，從而得出網路帶寬利用情況，修正估出的帶寬。
兩種演算法相輔相成，收端將估算的帶寬發送給發端，發端結合收到的帶寬以及丟包率，調整發送的帶寬。
下面具體分析兩種演算法：
2, 接收端帶寬估算演算法分析
結合文檔http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02以及源碼webrtc/moles/remote_bitrate_estimator/overuse_detector.cc進行分析
帶寬估算模型： d(i) = dL(i) / c + w(i) d(i)兩幀數據的網路傳輸時間差，dL(i)兩幀數據的大小差， c為網路傳輸能力， w(i)是我們關注的重點， 它主要由三個因素決定：發送速率， 網路路由能力， 以及網路傳輸能力。w(i)符合高斯分布， 有如下結論：當w(i)增加是，佔用過多帶寬（over-using)；當w(i)減少時，佔用較少帶寬（under-using)；為0時，用到恰好的帶寬。所以，只要我們能計算出w(i)，即能判斷目前的網路使用情況，從而增加或減少發送的速率。
演算法原理：即應用kalman-filters
theta_hat(i) = [1/C_hat(i) m_hat(i)]^T // i時間點的狀態由C, m共同表示，theta_hat(i)即此時的估算值
z(i) = d(i) - h_bar(i)^T * theta_hat(i-1) //d(i)為測試值，可以很容易計算出， 後面的可以認為是d(i-1)的估算值， 因此z(i)就是d(i)的偏差，即resial
theta_hat(i) = theta_hat(i-1) + z(i) * k_bar(i) //好了，這個就是我們要的結果，關鍵是k值的選取，下面兩個公式即是取k值的，具體推導見後繼博文。
E(i-1) * h_bar(i)
k_bar(i) = --------------------------------------------
var_v_hat + h_bar(i)^T * E(i-1) * h_bar(i)
E(i) = (I - K_bar(i) * h_bar(i)^T) * E(i-1) + Q(i) // h_bar(i)由幀的數據包大小算出
由此可見，我們只需要知道當前幀的長度，發送時間，接收時間以及前一幀的狀態，就可以計算出網路使用情況。
接下來具體看一下代碼：
[cpp] view
plain
void OveruseDetector::UpdateKalman(int64_t t_delta,
double ts_delta,
uint32_t frame_size,
uint32_t prev_frame_size) {
const double min_frame_period = UpdateMinFramePeriod(ts_delta);
const double drift = CurrentDrift();
// Compensate for drift
const double t_ts_delta = t_delta - ts_delta / drift; //即d(i)
double fs_delta = static_cast<double>(frame_size) - prev_frame_size;
// Update the Kalman filter
const double scale_factor = min_frame_period / (1000.0 / 30.0);
E_[0][0] += process_noise_[0] * scale_factor;
E_[1][1] += process_noise_[1] * scale_factor;
if ((hypothesis_ == kBwOverusing && offset_ < prev_offset_) ||
(hypothesis_ == kBwUnderusing && offset_ > prev_offset_)) {
E_[1][1] += 10 * process_noise_[1] * scale_factor;
}
const double h[2] = {fs_delta, 1.0}; //即h_bar
const double Eh[2] = {E_[0][0]*h[0] + E_[0][1]*h[1],
E_[1][0]*h[0] + E_[1][1]*h[1]};
const double resial = t_ts_delta - slope_*h[0] - offset_; //即z(i)， slope為1／C
const bool stable_state =
(BWE_MIN(num_of_deltas_, 60) * fabsf(offset_) < threshold_);
// We try to filter out very late frames. For instance periodic key
// frames doesn't fit the Gaussian model well.
if (fabsf(resial) < 3 * sqrt(var_noise_)) {
UpdateNoiseEstimate(resial, min_frame_period, stable_state);
} else {
UpdateNoiseEstimate(3 * sqrt(var_noise_), min_frame_period, stable_state);
}
const double denom = var_noise_ + h[0]*Eh[0] + h[1]*Eh[1];
const double K[2] = {Eh[0] / denom,
Eh[1] / denom}; //即k_bar
const double IKh[2][2] = {{1.0 - K[0]*h[0], -K[0]*h[1]},
{-K[1]*h[0], 1.0 - K[1]*h[1]}};
const double e00 = E_[0][0];
const double e01 = E_[0][1];
// Update state
E_[0][0] = e00 * IKh[0][0] + E_[1][0] * IKh[0][1];
E_[0][1] = e01 * IKh[0][0] + E_[1][1] * IKh[0][1];
E_[1][0] = e00 * IKh[1][0] + E_[1][0] * IKh[1][1];
E_[1][1] = e01 * IKh[1][0] + E_[1][1] * IKh[1][1];
// Covariance matrix, must be positive semi-definite
assert(E_[0][0] + E_[1][1] >= 0 &&
E_[0][0] * E_[1][1] - E_[0][1] * E_[1][0] >= 0 &&
E_[0][0] >= 0);
slope_ = slope_ + K[0] * resial; //1/C
prev_offset_ = offset_;
offset_ = offset_ + K[1] * resial; //theta_hat(i)
Detect(ts_delta);
}
[cpp] view
plain
BandwidthUsage OveruseDetector::Detect(double ts_delta) {
if (num_of_deltas_ < 2) {
return kBwNormal;
}
const double T = BWE_MIN(num_of_deltas_, 60) * offset_; //即gamma_1
if (fabsf(T) > threshold_) {
if (offset_ > 0) {
if (time_over_using_ == -1) {
// Initialize the timer. Assume that we've been
// over-using half of the time since the previous
// sample.
time_over_using_ = ts_delta / 2;
} else {
// Increment timer
time_over_using_ += ts_delta;
}
over_use_counter_++;
if (time_over_using_ > kOverUsingTimeThreshold //kOverUsingTimeThreshold是gamma_2， gamama_3=1
&& over_use_counter_ > 1) {
if (offset_ >= prev_offset_) {
time_over_using_ = 0;
over_use_counter_ = 0;
hypothesis_ = kBwOverusing;
}
}
} else {
time_over_using_ = -1;
over_use_counter_ = 0;
hypothesis_ = kBwUnderusing;
}
} else {
time_over_using_ = -1;
over_use_counter_ = 0;
hypothesis_ = kBwNormal;
}
return hypothesis_;
}
6. 如何在mcu中移植webrtc
方法步驟如下：【點擊免費試用，0成本啟動】
第一步，用客戶端比如Chrome瀏覽器，通過WebRTC相關的媒體API獲取圖像及聲音信源，再用WebRTC中的通信API將圖像和聲音數據發送到MCU伺服器。
第二步，MCU伺服器根據需求對圖像和聲音數據進行必要的處理，比如壓縮、混音等。
第三步，需要看直播的用戶，通過他們的Chrome瀏覽器，鏈接上MCU伺服器，並收取伺服器轉發來的圖像和聲音流。
想要了解更多關於webrtc的相關信息，推薦咨詢ZEGO即構科技。ZEGO即構科技自主研發的高音質語音視頻引擎，能夠提供實時清晰的多人語音通話獨立自研的語音前處理模塊（AEC, NS, AGC）能夠提供優於同類競品的處理效果，支持全帶語音處理。良好的抖動緩沖、前向糾錯和丟幀補償技術使引擎適應復雜的網路環境，提供低延時清晰流暢的語音視頻通話，在較差網路環境中自適應的找到延時與流暢的最佳契合點。
7. 基於開源WebRTC開發實時音視頻靠譜嗎
WebRTC是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術，在行業內得到了廣泛的支持和應用，成為下一代視頻通話的標准，所以來說還是靠譜的。
話說回來，雖然作為實時音視頻領域最火的開源技術，WebRTC 點對點的架構模式卻無法支持大規模並發，怎麼解決呢？即構自研WebRTC網關伺服器架構實踐就很好解決了這個問題。
Zego-Gateway架構的改進
在加入WebRTC網關之前，即構自研系統架構如下圖所示，主要分成兩部分，左邊是低延時用戶，而右邊是圍觀用戶。低延時用戶主要是通過ZEGO的實時傳輸網路進行推拉流。
在加入了WebRTC網關伺服器後（圖中紅線部分所示），即構的系統已經能全面支持網頁端視頻互動場景，同時實現了APP、微信小程序、WebRTC三端的連麥互通。
8. webrtc哪些程序放在伺服器
一) sipdroid
1）架構
sip協議棧使用java實現，音頻Codec使用skype的silk（Silk編解碼是Skype向第三方開發人員和硬體製造商提供免版稅認證(RF)的Silk寬頻音頻編碼器）實現。NAT傳輸支持stun server.
2）優缺點：
NAT方面只支持STUN，無ICE框架，如需要完全實現P2P視頻通話需要實現符合ICE標準的客戶端,音頻方面沒看到AEC等技術，視頻方面還不是太完善，目前只看到調用的是系統自帶的MediaRecorder，並沒有自己的第三方音視頻編解碼庫。
3）實際測試：
基於sipdroid架構的話，我們要做的工作會比較多，（ICE支持，添加迴音消除，NetEQ等gips音頻技術，添加視頻硬體編解碼codec.）,所以就不做測試了。
二) imsdroid
1)架構：
基於doubango(Doubango 是一個基於3GPP IMS/RCS 並能用於嵌入式和桌面系統的開源框架。該框架使用ANSCI-C編寫，具有很好的可移植性。並且已經被設計成非常輕便且能有效的工作在低內存和低處理能力的嵌入式系統上。蘋果系統上的idoubs功能就是基於此框架編寫) .音視頻編碼格式大部分都支持（H264(video)，VP8(video)，iLBC(audio),PCMA,PCMU,G722,G729）。NAT支持ICE（stun+turn）
2）效果實測
測試環境：公司區域網內兩台機器互通，伺服器走外網sip2sip
音頻質量可以，但是AEC打開了還是有點迴音（應該可以修復）。視頻馬賽克比較嚴重，延遲1秒左右。
3）優缺點
imsdroid目前來說還是算比較全面的，包括音視頻編解碼，傳輸（RTSP，ICE），音頻處理技術等都有涉獵。doubango使用了webrtc的AEC技術，但是其調用webrtc部分沒有開源，是用的編譯出來的webrtc的庫。如果要改善音頻的話不太方便，Demo的音頻效果可以，視頻效果還是不太理想。
三）csipsimple
1）sip協議棧用的是pjsip,音視頻編解碼用到的第三方庫有ffmpeg（video）,silk(audio),webrtc.默認使用了webrtc的回聲演算法。支持ICE協議。
2）優缺點：
csipsimple架構比較清晰，sip協議由C實現，java通過JNI調用，SIP協議這一塊會比較高效。其VOIP各個功能也都具備，包括NAT傳輸，音視頻編解碼。並且該項目跟進新技術比較快，官方活躍程度也比較高。如果做二次開發可以推薦這個。
3）實測效果
測試環境：公司區域網內兩台機器互通，伺服器走外網sip2sip
音頻質量可以，無明顯迴音，視頻需要下插件，馬賽克比imsdroid更嚴重。
四）Linphone
這個是老牌的sip，支持平台廣泛 windows, mac,ios,android,linux，技術會比較成熟。但是據玩過的同事說linphone在Android上的bug有點多，由於其代碼實在龐大，所以我暫時放棄考慮Linphone.不過如果誰有跨平台的需要，可以考慮Linphone或者imsdroid和下面的webrtc.。。。好像現在開源軟體都跨平台了。。。
五) webrtc
imsdroid,csipsimple,linphone都想法設法調用webrtc的音頻技術，本人也測試過Android端的webrtc內網視頻通話，效果比較滿意。但是要把webrtc做成一個移動端的IM軟體的話還有一些路要走，不過webrtc基本技術都已經有了，包括p2p傳輸，音視頻codec,音頻處理技術。不過其因為目前僅支持VP8的視頻編碼格式（QQ也是）想做高清視頻通話的要注意了。VP8在移動端的硬體編解碼支持的平台沒幾個（RK可以支持VP8硬體編解碼）。不過webrtc代碼里看到可以使用外部codec,這個還是有希望調到H264的。
總結：sipdroid比較輕量級，著重基於java開發（音頻codec除外），由於其音視頻編碼以及P2P傳輸這一塊略顯不足，不太好做定製化開發和優化。imsdroid,遺憾就是直接調用webrtc的庫，而最近webrtc更新的比較頻繁，開發比較活躍。如果要自己在imsdroid上更新webrtc擔心兼容性問題，希望imsdroid可以直接把需要的webrtc相關源碼包進去。csipsimple的話，都是圍繞pjsip的，webrtc等都是以pjsip插件形式擴充的,類似gstreamer. webrtc如果有技術實力的開發公司個人還是覺得可以選擇這個來做，一個是google的原因，一個是其視頻通話相關關鍵技術都比較成熟的原因。個人覺得如果能做出來，效果會不錯的。
9. 如何搭建SimpleWebRTC信令伺服器 / 藍訊
CDN加速節點就是專門用來做緩存的伺服器，把客戶源站的網站內容緩存到各地的CDN節點，從而使得各地的訪問者可以從就近的節點上訪問到想要的內容，加快訪問速度。