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节点，从而使得各地的访问者可以从就近的节点上访问到想要的内容，加快访问速度。