视频直播之优化移动端WebRTC通信

注意
本文最后更新于 2016-10-23,文中内容可能已过时。

本文探讨范围仅限于移动端优化,android和iOS都适用。

惯例,先上介绍

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

中文翻译大致意思:WebRTC是开源且免费的,可以用于浏览器和移动端的实时视频通讯,是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。

WebRTC通信最主要的配置,其实都在PeerConnection.java下的RTCConfiguration这个类里面,我们着重来看下这个类有什么。

java

public static class RTCConfiguration {
    public IceTransportsType iceTransportsType;
    public List<IceServer> iceServers;
    public BundlePolicy bundlePolicy;
    public RtcpMuxPolicy rtcpMuxPolicy;
    public TcpCandidatePolicy tcpCandidatePolicy;
    public CandidateNetworkPolicy candidateNetworkPolicy;
    public int audioJitterBufferMaxPackets;
    public boolean audioJitterBufferFastAccelerate;
    public int iceConnectionReceivingTimeout;
    public int iceBackupCandidatePairPingInterval;
    public KeyType keyType;
    public ContinualGatheringPolicy continualGatheringPolicy;
    public int iceCandidatePoolSize;
    public boolean pruneTurnPorts;
    public boolean presumeWritableWhenFullyRelayed;

    public RTCConfiguration(List<IceServer> iceServers) {
        iceTransportsType = IceTransportsType.ALL;

        bundlePolicy = BundlePolicy.BALANCED;

        rtcpMuxPolicy = RtcpMuxPolicy.NEGOTIATE;

        tcpCandidatePolicy = TcpCandidatePolicy.ENABLED;

        candidateNetworkPolicy = candidateNetworkPolicy.ALL;

        this.iceServers = iceServers;

        audioJitterBufferMaxPackets = 50;

        audioJitterBufferFastAccelerate = false;

        iceConnectionReceivingTimeout = -1;

        iceBackupCandidatePairPingInterval = -1;

        keyType = KeyType.ECDSA;

        continualGatheringPolicy = ContinualGatheringPolicy.GATHER_ONCE;

        iceCandidatePoolSize = 0;

        pruneTurnPorts = false;

        presumeWritableWhenFullyRelayed = false;
    }
}
;
  • IceTransportsType:收集的策略类型,目前可供选择的有ALL(全部收集),NOHOST(不收集host类的策略信息),RELAY(只使用服务器的策略信息,简言之就是不通过P2P,只走服务端流量),NONE(不收集策略信息,目前作用未知)。一般来说,如果你想减少流量,那么就用ALL,WebRTC会在能打通P2P情况下使用P2P;如果你想要保证客户端的联通率,那么RELAY是你最好的选择。
  • bundlePolicy:协商策略,balanced, max-compat, max-bundle,基本上是选择max-bundle,主要是防止另一个客户端属于策略不可协商型。
  • rtcpMuxPolicy:实时传输控制协议多路策略,negotiate, require,第一个是获取实时传输控制协议策略和实时传输协议策略,第二个只获取实时传输协议策略,如果另一个客户端不支持实时传输控制协议,那么协商就会失败。Tiki客户端测试发现Require比较适合移动客户端。
  • tcpCandidatePolicy:TCP候选策略控制开关,只有Enable和Disable,TCP策略虽然有握手来保证传输到达率,但这也是效率上最致命的,会极大拉低视频传输效率,所以建议不开启,除非有特别的需求。
  • candidateNetworkPolicy:候选网络策略,属于新出的策略,有ALL和LowCost两个值,暂时未知作用,如果有童鞋了解的话,可以交流下。
  • iceServers:服务端的候选地址,主要是用于客户端之间建立连接前的通信。
  • continualGatheringPolicy:收集策略时间段,有GATHER_ONCE和 GATHER_CONTINUALLY两种值,默认值为GATHER_ONCE,可以不用改。
  • keyType:加密类型,如果没有特殊需求,不建议更改。
  • 其他参数,有些属于M52之后新加的类型,还没有测试过,不敢妄下定论,还有一些属于测试后觉得不需要修改默认值的。

以上就是本人对WebRTC通信上的一些优化,如果大家觉得哪里有疑问或者错误,可以提出交流下。

相关内容