webrtc_webrtc 源码 - CSDN
webrtc 订阅
WebRTC,名称源自网页即时通信(英语:Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。 展开全文
WebRTC,名称源自网页即时通信(英语:Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。
信息
现归属公司
谷歌
释    义
支持网页浏览器进行实时语音对话或视频对话的API
应用平台
Google、Mozilla、Opera
中文名
网页实时通信
外文名
Web Real-Time Communication
缩    写
WebRTC
WebRTC特点
WebRTC实现了基于网页的视频会议,标准是WHATWG 协议,目的是通过浏览器提供简单的javascript就可以达到实时通讯(Real-Time Communications (RTC))能力。WebRTC(Web Real-Time Communication)项目的最终目的主要是让Web开发者能够基于浏览器(Chrome\FireFox\...)轻易快捷开发出丰富的实时多媒体应用,而无需下载安装任何插件,Web开发者也无需关注多媒体的数字信号处理过程,只需编写简单的Javascript程序即可实现,W3C等组织正在制定Javascript 标准API,目前是WebRTC 1.0版本,Draft状态;另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台,形成开发者与浏览器厂商良好的生态环境。同时,Google也希望和致力于让WebRTC的技术成为HTML5标准之一,可见Google布局之深远。WebRTC提供了视频会议的核心技术,包括音视频的采集、编解码、网络传输、显示等功能,并且还支持跨平台:windows,linux,mac,android。
收起全文
  • 本课程讲述如何使用OC 实现1V1 Android端实时音视频通信 包括如何使用nodejs开发WebSocket信令服务器 理解WebRTC媒体的交互流程 coturn服务器搭建 Android音视频客户端开发
  • webrtc入门与实战视频培训课程是通过作者多年经验总结出的一套webrtc入门教程,学完此课程,你能搭建出一套android互通或者web互通或者android对web互通的webrtc服务器,此课程由浅入深讲解了从编译到完整搭建一套...
  • 在线教育的兴起和5G时代的到来对于WebRTC来说是一次很好的机遇,现在使用WebRTC技术的公司越来越多,学习和掌握WebRTC对于音视频开发者而言已经成为必要的技术之一。 该课程将通过入门和实战,带你快速入门WebRTC...
  • Webrtc实时音视频通话实战视频培训教程概况:本课程完全基于webrtc实战来讲解,例如搭建webrtc服务器、webrtc命令。通过本课程的学习,学员便可搭建自己的webrtc服务器,实现web、app、微信之间的音视频通话功能,且...
  • 工业级webrtc项目实战

    2019-10-10 15:33:44
    1、简要介绍webrtc的技术方案 2、利用webrtc实现工业级视频会议 3、将视频会议与AI智能相结合实现 4、从实践中掌握webrtc原理 5、掌握产品研发流程,webrtc架构 6、 对webrtc前景展望
  • 实时音视频应用的爆发,也使得WebRTC(Web Real-Time Communication,网页实时通信技术,)技术成为了人们关注的焦点。如何打造自己的WebRTC 服务器呢?下面我先来介绍一下WebRTC 服务器的一些基本内容:   ...

    1. 引言

     

    近年来,直播竞答、网络游戏直播等新的实时音视频通讯场景不断推陈出新,并成为引领互联网娱乐风向的弄潮儿。实时音视频应用的爆发,也使得WebRTC(Web Real-Time Communication,网页实时通信技术,)技术成为了人们关注的焦点。如何打造自己的WebRTC 服务器呢?下面我先来介绍一下WebRTC 服务器的一些基本内容:

     

    • 开源的WebRTC 服务器介绍

    • WebRTC服务端整体分析

    • 通信优化

    • WebRTC的未来展望

       

     

    首先,我们会先来了解下一些开源的服务器是怎么做的,我们做事情,在没有头绪的基础上,参考和模仿可能是一种必然流程,毕竟站在巨人的肩膀上,我们的视野才更加开阔。

    其次,通过形形色色的开源服务器介绍和理解,我们初步的去分析一个WebRTC 服务器究竟包含哪些模块,又是一个什么样的组织架构和层次关系。后面在服务器搭建后面临的丢包和多人通话问题又有什么解决方式。最后就是展望一下整个WebRTC未来发展。

     

    2. 开源的WebRTC 服务器介绍

     

    我们进入第一部分:WebRTC开源服务器介绍,这个模块我选择了我认为很有代表意义的3种类型的WebRTC 开源服务器

     

    • 大而全的Kurento

    • 务实主义的Licode

    • 小而美的Mediasoup

     

    大而全的Kurento

     

    之所以称Kurento为大而全,是因为Kurento 强大的滤镜和计算机视觉,我们看这张图:

     

     

    Kurento功能图                          

     

    通过这张图我们了解到Kurento不仅仅包含了普通流媒体服务器的SFU MCU Transcoding  Recording等基本功能,还包含了强大的滤镜和计算机视觉处理功能,而且,在整体的功能上不仅仅包含WebRTC 模块还有很多其他协议支持,诸如SIP RTMP RTSP 等协议,更准确的说Kurento 更像是一个融合通信平台,而且Kurento,基于插件式编程方式,很容易扩展自己的功能模块。

     

    Kurento 在应用中有哪些问题,或者说,哪些是优势,哪些是劣势呢,我们看下面:

     

    优势:

     

    • 文档齐全无论API使用文档,还是部署文档都很齐全

    • 功能强大,强大的路径和计算机视觉处理

    • 模块化编程,方便扩展,这是对开发者很友好的地方

    • 使用方便,客户端服务端都有专门的API 组件 接入系统,而且服务器端提供了J2EE node.js两种接口文档,覆盖很齐全

     

    劣势:

     

    • 代码太多太庞大,可能需要开发者有足够的功力才能驾驭这把屠龙刀

    • 还一个重要原因就是性能比较差

     

    小而美的Mediasoup

     

    Mediasoup是一个很新的WebRTC服务器,专注WebRTC 的相关功能开发,专注做好这一件事,很小确很美。下面这样图是Mediasoup 大致的一个基本架构图:

     

    Mediasoup 架构

     

    Mediasoup

     

    优势:

     

    • 性能优秀

    • 支持很多的WebRTC 新特性(PlanB  UnifiedPlan simulcast)

    • 同时支持ORTC和WebRTC 的互通

     

    劣势:

     

    • 功能比较少

    • 代码和架构相对来比较晦涩一点

    • 信令模块只提供node.js 版本

       

     

    务实主义的Licode

     

    说了两款极端的WebRTCserver ,我们最后讲一个务实主义的Licode ,为什么称Licode 为务实主义?Licode 这款服务器完全是站在一个PAAS 平台,一个业务的角度去思考问题,去构建整个系统,很务实,很实际,我们看Licode架构图:

     

    Licode 架构图

    架构很清晰:

     

    用户端:

    • 房间信令模块

    • WebRTC媒体模块

     

    服务端:

     

    开发者方面:

     

    业务接入的API模块

     

    服务器内部:

     

    • 面向开发的API 服务模块,提供基本的房间和用户操作

    • 房间服务器模块,提供基本的房间信令支持

    • 媒体模块,完成服务端的WebRTC 媒体功能

     

    整个服务架构内部各个服务模块通过MQ 消息总线进行数据通信,做了一个服务器要做的基本功能,同时微服务化,很符合现在服务器开发的方向。

     

    Licode 作为WebRTC 服务器有很多优势

     

    • 功能齐全扩展方便,鉴权,存储,融合通信一应俱全

    • 代码扩展简单,预留了足够的扩展接口

    • 部署简单,一键脚本安装,很方便

     

    缺点:

    • 内部模块说明比较少

    • 性能一般

    • 服务端只提供的node.js 版本

     

    总结

     

    这么多服务器怎么选择呢?看自己的业务需求,团队能力,项目周期。

     

    有能力的团队可以尝试选Kurento,讲求平衡快速选择Licode,追求极致Mediasoup 很符合选择。

     

    3 WebRTC 服务端分析

     

    前面我们讲了很多开源WebRTC服务器,到底WebRTC 是个什么东西,又包含哪些模块呢,我们从下面几个方面逐一分析:

    • 基本组件

    • 层次架构

     

    基本组件

    基本模块

    图中我列出了基本的组件:

     

    • Rtp/Rtcp媒体打包协议

    • Dtls加密协议

    • ICEP2P 传输协议

    • SDP系统控制协议,控制整个系统的运行行为

     

    Rtp/Rtcp Dtls ICE是基本组件相对实现比较容易,这个我们不做过多介绍,我们着重介绍下SDP 这个协议

     

    SDP 演进

     

    SDP 伴随着WebRTC 的发展,经历了很多变化,我把这个过程归纳为两个阶段:

    • PlanA单流时代

    • PlanB/UnifiedPlan多流时代

       

     

    PlanA

     

    每个stream 对应一个peer 多个stream 对应多个peer,整体运行图如下:

     

     

     

    PlanA

     

    下面是PlanA 的SDP 结构:

     

    没什么新奇的地方,大家都应该比较熟悉了,我们不做介绍了。

     

    PlanB UnifiedPlan:

     

    one peer multi stream, 单个peer 可以拥有多个steam ,整体运行图如下:

     

    PlanB UnifiedPlan

    其中PlanB 是chrome SDP 多流方案,而UnifiedPlan是Firefox 的多流标准同时也是JSEP的标准多流方案,所以UnifiedPlan是我们关注的重点。

     

    我们先来看看PlanB 的多流SDP 大致内容:

     

    PlanB SDP

     

    PlanB 和 PlanA 相比,基本组织形式是相同的。我们看标红的地方,PlanB 组织多流的方式是通过msid来完成,每个msid 对应一条媒体流. 每个msid下面是自己的传输信息,所以在PlanB 方案下,我们可以通过msid来标记用户。

     

    我们再来看看UnifiedPlan,下面是一个UnifiedPlan 部分SDP:

     

    UnifiedPlan

     

    UnifiedPlan通过加多个m 标签,来组织多流,每条流分配一个m 标签,后面跟着自己的attribute 描述,另外group 行业进行了修改,以每个track 进行描述。当然UnifiedPlan 里面也是msid 可以用来标记用户。

     

    相比 PlanB,UnifiedPlan SDP更加清晰,自然,当然问题是数据量比计较大,因为有很多冗余字段,当然作为JSEP 的标准,我们必须更加关注UnifiedPlan 方案。另外Firefox 里面mid 长度不能超过16位,在大家的服务器上产生UnifiedPlan 格式的SDP时注意一下。

    PlanBUnifiedPlan 方案优势:

     

    • 客户端single peer, 减少开发难度,无论 MCU 模式还是SFU 模式,客户端只需要创建一个peer

    • 减少端口占用,加强系统安全

     

    WebRTC 层次架构

     

    说完基本组件,我们开始介绍WebRTC 服务端,分3个层面:

     

    接口层

     

    接口层主要为PeerConnectionInterface接口实现,主要提供诸如一下内容:

    控制层

     

    控制层也就是我们所说的SDP 模块,控制整个系统的运行表现,包括编解码参数,流控方式,Dtls 加解密参数以及ICE穿透用的地址候选。

     

     

    传输层

     

    先看图:

     

    传输层分为3个层次,媒体打包(RTP/RTCP),数据安全(DtlsTransport),Ice P2P 传输模块(IceTransport)。

     

    了,这里我们了解全部系统组件,将系统组件叠加,我们就得到了,下面是一个完整的WebRTC 组件的一个层次结构:

     

     

    分为3层:接口层,提供基本的peer 接口功能,控制层,主要是SDP 的解析和生成工作,最后传输层,提供媒体打包,传输,流控,安全,ICE 等功能。

     

    4. 通信优化

     

    分两个层面去讲:

     

    • 对抗丢包

    • 多人通话

     

    对抗丢包

     

    • NACK

    使用场景 low RTT 或者延时不敏感场景

     

    • FEC

     

    冗余换取实时性和丢包。增强带宽抢占能力,这才是FEC 最主要的用途。

     

    两种方式各有优缺点,NACK代价是延时,FEC的代价是带宽,显然在高清会议中不适用FEC 方式。比较可取的方式是FEC+NACK, 低延时环境下,尽量采用重传,高延时生成适度的FEC数据包,对数据进行选择性重传。

     

    多人通信

     

    多人通信是一个令人的头疼的问题,因为面临以下几个问题:

     

    • 不同的用户网络带宽

    • 不同的运营商

     

    不同用户网络带宽

     

    先看第一个,我们都知道在通信中,用户的带宽往往是不对等的,怎么样做到按需供给,总体来说我们有一下几种方式:

     

    • 转码

    • SVC 分层编码

    • Simulcast(多流方案)

     

    先转码方案:

     

     

    服务端对用户发来的数据进行二次编码,服务端根据用户的网络情况,提供给用户不同质量的码流,这种方式服务压力大,延迟大,硬件成本高,比较适合小规模视频会议,或者发言人较少的场景。

     

    SVC方案:

     

    编码器产生的码流包含一个或多个可以单独解码的子码流,子码流可以具有不同的码率,帧率和空间分辨率。

     

    分级的类型:

     

    时域可分级(Temporalscalability):可以从码流中提出具有不同帧频的码流。

    空间可分级(Spatialscalability):可以从码流中提出具有不同图像尺寸的码流。

    质量可分级(Qualityscalability):可以从码流中提出具有不同图像质量的码流。

     

    分层结构图

     

    SVC可以组合提供不同质量的码流,服务器可以根据用户网络情况选择一路进行转发,

    SVC 应该是最好的对抗丢包的方式,可惜WebRTC 不能用,这里我们不做深入研究,H264SVC RTP打包情况可以参考rtc6190

     

    Simulcast(多流) 方案:

    如图:

     

    客户端同时发送多种码率到服务端,然后服务端进行选择性转发,这种方案,发送端上传压力大,而且编码压力也大,但是,这是唯一一种WebRTC 支持的针对多人通话的技术。

    下面我们看看如何开启这种技术:

     

    • Chrome 端  包括js 和 native 源码端:

       

     

    Chrome并没有提供直接的接口用于开启多流方案,我们在Chrome 系列中只能通过修改的本段的SDP 来开启多流方案,如图:

     

     

     

    通过修改SDP 加入SIM 标志开启多流,开启几条,就多加入几条ssrc 信息

     

    • Firefox 端:

       

     

    Firefox 提供了直接的接口用于开启多流方案,如下图:

     

    Firefox直接通过RtpSender 的 SetParameters 接口开启多流,简单方便,这也是Firefox 相比较Chrome更好的地方,更加遵从WebRTC标准。

     

    另外在Rtp的传输上Chrome和Firefox 是不同的:

     

    >>>Chrome:

     

    通过ssrc 对应多流方案,每个ssrc对应一种多流

    a=ssrc-group:SIM2098403539(low) 2098403540(medium) 2098403541(high)

     

    >>>Firefox:

     

    通过urn:ietf:params:rtp-hdrext:sdes:rtp-stream-idRtp协议头的扩展来完成多流和ssrc 的对应关系,进而完成传输。

     

    不同运营商

     

     

    中国运营商主要有电信 移动和联通,另外包括很多小运营上和结构运营商,运营商很多,而且由于运营商之间的网络宽口问题,跨网通信延迟大,网络不稳定,针对这种情况,我们基于DNS重定向,分配给用户运行商相同的服务器,这里说一句,运营商分类的判断,需要很久的运维经验和数据作为支撑,这也是我们的PP云的优势所在,我们PP云有十几年的运营数据作为支撑,这些数据不仅帮我们构建更加快速的服务器网络,而且还可以帮我们为用户定位到最优的服务器,进而解决最后一英里的网络传输问题。

     

    5 WebRTC 未来展望

     

    为AI 赋能

     

    AI 的发展,赋予了WebRTC更多的应用空间,比如基于人脸和语音识别的网站和APP 登录系统,前端通过WebRTC 进行视频数据的采集和传输,后台通过AI智能分析比对结果,进而完成登录,简单,方便。

     

    安防领域

     

    我们知道安防领域比较多的协议包括ONVIF,GB28181 RTSP,这几个协议在网页端无法直接观看,智能借助于插件,插件面临兼容和安全问题,体验很差,有的摄像头支持RTMP观看,但是很遗憾,2020年flash 将退出历史舞台,HLS延时大,而无插件,极速都是WebRTC 的优势所在,我相信不救的将来WebRTC 在安防领域会占据一席之地。

     

    6. 结语:

     

    WebRTC1.0 已经定稿,这为WebRTC的未来发展提供了方向,并且WebRTC 无论是应用还是社区都处于高速发展状态,并且Google也在不断地提供和完善WebRTC 的相关功能,我相信WebRTC 的未来无可限量,分享结束,谢谢大家。

    展开全文
  • webRTC简介

    2019-08-06 13:46:38
    WebRTC 的三种任务 获取音频和视频 传达音频和视频 传达任意数据 三种主要的JavaScript APIs MediaStream(aka getUserMedia) RTCPeerConnection RTCDataChannel ###MediaStream 代表一种 音频 或者/和 语音流. ...

    关注微信公众号(瓠悠笑软件部落),一起学习,一起摸鱼
    huyouxiao.com
    本文是Google开源大会对WebRTC的讲解。自己看视频做的笔记。英文好的同学,建议直接看视频。原视频地址
    如果访问不了,可以访问我的公众号。里面有视频:视频带文字版
    喜欢的话,别忘了点击好看。谢谢你的支持。

    WebRTC 的三种任务

    • 获取音频和视频
    • 传达音频和视频
    • 传达任意数据

    三种主要的JavaScript APIs

    • MediaStream(aka getUserMedia)
    • RTCPeerConnection
    • RTCDataChannel

    MediaStream

    • 代表一种 音频 或者/和 语音流.
    • 可以包含多个 “tracks”
    • 通过 navigator.getUserMedia() 获取一个 MediaStream
      MediaStream

    MediaStream

    aka getUserMedia

    var constraints = {video: true};
    
    function successCallback(stream) {
    var video = document.querySelector("video");
    video.src = window.URL.createObjectURL(stream);
    }
    
    function errorCallback(error) {
      console.log("navigator.getUserMedia error:", error);
    }
    
    navigator.getUserMedia(constraints, successCallback, errorCallback);
    
    

    在线二进制摄像头

    在线摄像头

    Constraints

    • Controls the contents of the MediaStream
    • Media type, resolution, frame rate
    video: {
      mandatory: {
        minWidth: 640,
        minHeigh: 360
      },
      optional [{
        minWidth: 1280,
        minHeigth: 720
      }]
    }
    

    getUserMedia + Web Audio

    // success callback when requesting audio input stream
    function gotStream(stream) {
       var audioContext = new webkitAudioContext();
       // create an AudioNode from the stream
       var mediaStreamSource = audioContext.createMediaStreamSource(stream);
    
     // connect it to the destination or any other node for processing!
     mediaStreamSource.connect(audioContext.destination);
    }
    

    确保打开了Chrome 浏览器里面 about:flags 里面的 Web Audio Input

    获取用户切图 gUM screencapture

    var constraints = {
      video: {
        mandatory: {
           chromeMediaSource: 'screen'
        }
      }
    }
    navigator.webkitGetUserMedia(constraints, gotStream);
    

    RTCPeerConnection

    audio 和 video 点到点之间的链接通信

    Communicate Media Streams

    Communicate Media Streams

    RTCPeerConnection 做了很多

    • 信令处理
    • 解码操作
    • 端到端的通信
    • 安全
    • 带宽控制

    WebRTC 架构

    WebRTC architecture

    RTCPeerConnection 样例

    pc = new RTCPeerConnection(null);
    pc.onaddstream = gotRemoteStream;
    pc.addStream(localStream);
    pc.createOffer(gotOffer);
    
    function gotOffer(desc) {
      pc.setLocalDescription(desc);
      sendOffer(desc);
    }
    
    function getAnswer(desc) {
      pc.setRemoteDescription(desc);
    }
    
    function getRemoteStream(e) {
      attachMediaStream(remoteVideo, e.stream);
    }
    

    RTCDataChannel

    端到端之间的任意数据的双向通信
    Communicate arbitrary data

    RTCDataChannel

    • Same API as WebSocket
    • Ultra-low lantency 超低延迟
    • Unreliable or reliable 根据应用场景选择是速度重要,还是可靠性重要。比如传文件,需要搞可靠性。而传游戏数据,数度更重要。
    • Secure 保证传输的数据在接收后能够以正确的方式解码。

    RTCDataChannel API

    var pc = new webkitRTCPeerConnection(servers, {optional: [{RtpDataChannels: true}]};
    
    pc.ondatachannel = function(event) {
       receiveChannel = event.channel;
       receiveChannel.onmessage = function(event) {
          document.querySelector("div#receive").innerHTML = event.data;
       };
    };
    
    sendChannel = pc.createDataChannel("sendDataChannel", {reliable: false});
    
    document.querySelector("button#send").onclick = function() {
      var data = document.querySelector("textarea#send").value;
      sendChannel.send(data);
      };
    

    github ShareFest

    Servers and Protocols

    Peer to Peer - 但是我们需要服务器.

    Abstract Signaling

    • 需要交换 ‘session description’ objects.
      • 我支持什么样的格式,我想要发送什么
      • 端到端之间建立链接时,需要的网络信息
    • 可以使用任意 messaging mechanism,比如: web sockets, Google Cloud Messaging, XHR
    • 可以使用任意 messaging protocol . 比如:JSON,或者标准的协议: SPI XMPP。

    Signaling Diagram

    Signaling Diagram

    An RTCSessionDescription

    An RTCSessionDescription

    STUN and TURN

    P2P in the age of firewalls and NATs
    端到端之间 session 完整的路径。

    在很早以前,这不是问题。人们知道对方的公网IP地址就可以直接连接进行通信。
    An idea world

    但后来有了NAT, NAT分发所谓的私有IP地址.而私有IP地址不能用于建立链接通信。我们就无法建立真正的端到端通信。除非我们有公共地址。所以引入了STUN技术。
    The real world

    STUN

    • 告诉我我的公网IP地址是多少. 当一个request 发送到STUN Server的时候,STUN Server查看这个请求的来源地址,并把地址放到 packet里面,然后发回去。所以现在WebRTC 知道 Peer 的公网IP地址了,之后STUN server 就不会参与到 Peer 与 Peer 之间的通信链路中去了。也就不需要转发 media。
    • 一个简单的 Server,运行成本低
    • Data flows peer-to-peer
      STUN
      通常情况下,是可以建立通信的,但不是在所有的情况下都能正常工作。所以引入了TURN 技术。

    TURN

    • 如果 peer-to-peer 通信失败的话,提供一个 cloud fallback.
      当无法建立端到端的链接时,转而调用云服务中的 relay。请求:给我一个公共的IP地址。由于这个公共地址是在云服务上。任何人都可以和他建立链接。也就以为着这个call可以建立起来。即使你在一个受限制的网络环境中,甚至在一个网络代理后面。
    • 数据是通过 server 发送的,使用 server 的带宽
      缺点是,由于数据实际上是通过服务器中继的,因此会产生运营成本。但这意味着这个通话可以在几乎所有的网络环境下正常的工作。
    • 确保 call 可以在绝大数网络环境下正常工作。
      TURN

    现在,一方面,我们有STUN,它超级便宜,但面对复杂的网络环境,会不可用。我们有TURN。他通常都可用。但会占用服务器的带宽。这两种方案,如何选择最好的方案呢?

    先尝试使用STUN Server 建立链接,如果不行,我们无法穿透NATs. s所以,我们回过头来,接着我们唯一能用的是TURN,把 media 数据从我们的发起 peer, 经过NAT, 再经过 TURN server 发送给另一端的 peer. 这些都是通过 ICE 技术实现的。

    ICE

    • ICE: 一个用于链接 Peers 的框架。
    • 尝试为每一个 call 找到最佳的通信路径。
    • 绝大多数 calls 都可以使用 STUN(webrtcstats.com);
      Video Calls

    部署 STUN/TURN

    • stun.l.google.com:19302
    • WebRTC stunserver, turnserer 建议取名的时候,取一个长长的名字以确保唯一性。
    • rfc5766-turn-server 他有 Amazon VM 镜像。你可以下载下来,部署到云服务器上去,你就可以给你的用户提供 TURN server 了。
    • restund 另外一个 TURN server,我们使用过,效果很好。
      WebRTC code package 里面有 STUN 和 TURN 的源代码。

    安全 Security

    在WebRTC开始的时候,就考虑了安全问题

    • 强制加密 media 和 data . 所有传输的数据都使用标准的 AES 加密。
    • Secure UI, explicit opt-in . 只有用户明确地选择了使用麦克风和摄像头,WebRTC才可以用这些功能。
    • Sanboxed, no plugins. WebRTC 运行在Chrome 浏览器的 沙盒 里面。
      所以即使有人试图攻击chrome里面的webRTC. 浏览器和用户都会得到完整的保护。
    • WebRTC Security Architecture WebRTC 安全架构

    Secure pathways 安全的传输方式

    • Signaling 用HTTPS加密
    • Audio/Video 使用SRTP加密
    • Data 使用DTLS(Datagram TLS) 加密

    Secure pathways

    Architecutres

    如果有多个call,比如一个多方会议,我应该如何构建我的应用程序?

    Peer to Peer: 1 对 1 的 call

    one-to-one-call

    Mesh(网孔):小型的多方会议.

    Mesh 表示每一个peer 都会连接到另外所有的其他peer。

    small-n-way-call
    这样也很简单,因为他们之间的链接不涉及服务器服务器和其他东东,比如信令。但有缺点: 假设有N个Peer参与通信,每一个Peer要发送的数据,必须将数据复制N-1分,分别发送给其他N-1个Peer. 这将有对应的CPU和带宽消耗。所以这取决于你要发送的media类型。对于Audio,开销要大一些。对应Video,开销要小一些。拓扑图中参与通话的Peers数量因此会收到限制. 如果某一个Peer是手机设备。CPU和带宽吃紧。限制更明显。
    为了解决这个问题,引入另外一种架构。

    Star: medium N-way call 星形架构

    star artitecture
    从所有peer里面找到一个性能最强的。由它从当会话的中心角色。我们称之为 the focus for the call. foucs 实际负责接收数据,复制并转发给所有其他Peers 或者 endpoints. 但是我们要处理多方的高清视频流(HD video streams). focus 的任务就有点吃不消了。所以对于大型的多方会话,需要使用MCU。

    MCU multipoint control unit. 多点控制单元

    large N-way call
    MCU 是一个为传递大量音频和视频而定制的服务器。它可以做各种事情. 它可以选择 stream 并转发. 它实际上可以混合音频或视频数据。它还能录制。如果一个Peer 掉线了,MCU不会中断整个会议,因为MCU要负责所有的Peer的会话,而不单单是某一个Peer。

    Beyong browers 不仅仅限制于在浏览器中使用。

    Phones and more

    • 容易和非浏览器设备集成
    • sipML5 开源的 JavaScript SPI client. 可以用于标准的SIP设备。
    • Phono 开源的 JavaScript phone API
    • Zingaya embeddable phone widget
      Zingaya PSTN

    创建一个 WebRTC app

    chrome://webrtc-internals
    在这里可以看到webRTC API 调用的日志,你可以debug.
    webrtc-internals

    adapter.js

    让你在所有版本的浏览器里面使用同样的代码

    • 移除了厂商前缀(vendor prefixes)
    • 将 Chrome/Firefox 的差异做了抽象处理。
    • 最大限度地减少规范流失的影响(minimizes effects of spec chrun)
      实际上 webRTC 规范的更新频率非常快,对于一个特定的浏览器,这些API 不能一直匹配最新版本的规范。adapter.js可以帮助Web开发人员隔离浏览器之间的差异和版本之间的差异。因此我们确保adapter.js始终实现最新的规范,然后向下发送到版本支持的任何内容。所以新的API发布的时候,不需要更改开发人员的代码,只需要更新一下adapter.js 文件就可以了。

    JavaScript frameworks

    • Video chat:
    • Peer-to-peer data:
      • PeerJS
      • Sharefest

    SimpleWebRTC

    很方便的 peer-to-peer 视频和语音

    var webrtc = new WebRTC ({
      localVideoEl:  'localVideo',
      remoteVideosEl: 'remoteVideos',
      autoRequestMedia: true 
    });
    
    webrtc.on('readyToCall', function (){
      webrtc.joinRoom('My room name');
    });
    

    PeerJS

    方便的 peer-to-peer data

    var peer = new Peer('someid', {key: 'apikey'});
    peer.on('connection', function(conn) {
       conn.on('data', function(data) {
       // will print 'hi!'
       console.log(data);
       });
    });
    
    
    // connecting peer
    var peer = new Peer('anotherid', {key: 'apikey'});
    var conn = peer.connect('someid');
    conn.on('open', function() {
       conn.send('hi!');
    });   
    

    javascript 并不用关心产品方面的服务特性,比如 信令,STUN 和 TURN 服务。幸运的是,OpenTok 和 vLine 为我们提供了这些服务。你只需要注册这些服务,获取API key, 就可以使用他们的产品功能发起 call. 触达世界的每个角落。他们还制作了可以轻松放入WebRTC应用程序的UI小部件.所以你能快速的开发和运行 WebRTC app.

    Services

    • 完成 video services:
      • OpenTok (acuqired by Telefonica Digital)
      • vLine

    最新版chrome 已经支持 HD video quality 和 full-band audio quality.

    更多信息:
    webrtcbook.com
    io13webrtc.appspot.com

    原视频地址

    webRTC

    展开全文
  • WebRTC协议学习之一(WebRTC简介)

    什么WebRTC

    WebRTC,名称源自网页即时通信(英语:Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。谷歌2011年6月3日宣布向开发人员开放WebRTC架构的源代码。这个源代码将根据没有专利费的BSD(伯克利软件发布)式的许可证向用户提供。开发人员可访问并获取WebRTC的源代码、规格说明和工具等。
    WebRTC使用安全实时传输协议(Secure Real-time Transport Protocol,SRTP)对RTP数据进行加密,消息认证和完整性以及重播攻击保护。它是一个安全框架,通过加密RTP负载和支持原始认证来提供机密性。WebRTC的安全特性是其可靠性的重要组成部分,其基础全部围绕实时传输协议(Real-time Transport Protocol)进行。
    详情参看:WebRTC

    要学习WebRTC需要先理解一些基本概念

    • 什么是实时传输协议?

    实时传输协议(RTP)是专为多媒体电话(VoIP,视频会议,远程呈现系统),多媒体流(视频点播,直播)和多媒体广播而设计的网络协议。它最初由RFC1889中的IETF指定。RTC最初是为了协助IETF音频-视频传输工作组涉及寄给地理上分散的成员的视频会议而创建的。目前,RFC3550中指定的v2是过去15年中一直在使用的v2。

    1. RTP的设计基于应用层框架和集成层处理的基本原理。它提供源和负载类型标识,流同步,丢包和重新排序以及媒体流监控。
    2. RTP使用RTP控制协议(RTCP)报告媒体流的性能。
    3. 在这个过程中,媒体发送端发送封装在RTP中的编码媒体。它还发送RTCP发送端报告,这有助于不同媒体流的额播放同步。接收端维护一个抖动缓冲区,对媒体数据包进行重新排序,并根据数据包中编码的定时信息进行播放。如果数据包丢失,接收端进行数据包恢复或者隐藏错误。最后,在RTCP接收端报告中接收机粗略或详细地对统计数据进行报告,使媒体发送端能够调整其媒体编码速率,变成更好的编解码器或改变前向纠错量。
    • RTP数据包报头格式

    RTP包报头格式分为四个部分:同步源标识符(synchronization source identifier),贡献源标识符(contributing source identifier),时间戳(timestamp),序列号(sequence number),以及负载类型(payload type)。

    1. 同步源:同步源协助确定源端点。 当端点发送需要同步的多个媒体流时很有用。
    2. RTP时间戳:RTP时间戳有助于在适当的时间播放接收到的数据包,并从RTP数据包中重组媒体帧。
    3. RTP序列号:RTP序列号帮助识别丢失的数据包并且在数据包不按顺序到达的情况下重新排序数据包。
    4. 负载类型:负载类型描述了它所携带的媒体数据的编码。每个编解码器必须指定其相应的负载类型。
    • RTCP报告

    RTCP报告有三种:发送端报告,接收端报告和扩展报告。

    1. RTCP发送端报告
      发送端使用RTCP发送端报告来帮助同步媒体流。为了实现这一点,它将各个媒体流的RTP时间戳与时钟时间相关联,并通知接收端当前的分组速率和比特率。
    2. RTCP接收端报告
      接收端测量输入流并在RTCP接收端报告中报告粗粒度的传输统计。此报告包括当前的丢包比例,接收到的最高序列号,并有助于计算往返时间。
    3. RTCP扩展报告
      RTCP扩展报告由端点用来描述复杂的度量标准,而不是RTCP接收端报告中所公开的。这包括相关的性能监控和拥塞控制指标,如抖动缓冲之后表,数据包延时变化,延时指标,丢弃数据包数量,体验质量等。新的度量标准也可以定义,只要它们涉及测量的内容,测量方式以及向其他端点报告的方式。
    • RTP负载格式是什么样的?

    定义负载格式需要识别媒体数据包的编码。这些编码可以是两种方式中的一种:编解码器专用的,例如H.264,H.263,H.261,MPEG-2,JPEG,G.711,G.722或AMR;通用的,例如前向纠错(FEC),NACK或多路复用流。
    负载文件通常为媒体编解码器指定一个定义明确的数据包格式,并描述编解码器的两种规则:聚合规则(aggregation rules)和碎片规则(fragmentation rules)。聚合规则是为编解码器定义的,与IP最大传输单元(例如音频)相比,这些编解码器产生几个小帧。碎片规则是为产生大帧的编解码器定义的,例如视频编解码器的I帧。将大型帧分成较小的数据包而不依赖于IP碎片,主要是因为IP碎片数据包通常在网络中被丢弃,尤其是通过NAT或防火墙的时候。

    • 什么是RTP报头扩展?

    RTP报头扩展旨在传送独立于媒体的信息。 更具体地说,它们携带的数据通常可以适用于多种负载格式,并且需要比发送RTCP报告更频繁地进行报告。

    例如,在为交互媒体发送NACK数据包时,每隔几十毫秒会产生双向媒体流和RTP数据包。在这种情况下,RTP报头扩展可以指示哪些序列号被正确接收或丢失。因此,他们不完全依赖RTCP接收端报告发送NACK或ACK。
    使用报头扩展可能非常有用,因为它们向后兼容。不了解它们的端点可能会忽略它们。此外,它们是通用的,因为不需要为每个媒体编解码器重新定义相同的扩展名。
    RTP报头扩展有多种用途,包括报告网络发送时间戳和媒体会议中跨多个流均衡客户端的音频级别。

    • 什么是RTCP报告间隔?

    使用RTP,通过发送RTP媒体数据包和接收RTCP反馈数据包创建一个闭环。RTCP反馈间隔通常是会话带宽的一小部分,不会影响媒体流量。RTCP报告间隔由会话中的同步源数量和会话带宽决定。

    1. 虽然会话带宽预计将在参与者之间进行分配,但实际上通常是预期同时活动的发送端的平均吞吐量的总和。例如,在音频会议中,会话带宽将是一个发送端的带宽。但是,对于视频会议,会话带宽取决于显示的用户数量。为了管理这个,会话带宽由会话管理层给出,因此为每个参与者计算相同的RTCP间隔值。
    2. 会话带宽的5%应该分配给控制流量。
    3. 在具有大量接收端和少量发送端的场景中,四分之一的报告带宽应由发送端平均分配,其余四分之三专用于接收端。这允许新的参与者快速从发件人报告接收CNAME和同步时间戳。对于新的参与者,RTCP时间间隔减半以快速声明他们的存在。
      推荐的RTCP最小值为5秒。这适用于单向链路,或适用于不需要检测接收质量到的会话。
    4. 减少的最小值是360除以会话带宽(以秒为单位)。它适用于单播双向多媒体会话的参与者,并适时发送反馈消息来执行拥塞控制或错误修复。
    • 基于RTCP反馈的扩展RTP文件

    在端点检测到数据包丢失或者通过报告间隔中途发生拥塞的情况下,RTCP报告不能提前发送,端点必须等待下一个计划的RTCP报告。这会导致媒体比特率不稳定和振荡。为了解决这个问题,端点实现了基于RTCP的反馈的扩展RTP配置文件。这是RTP默认时间规划的扩展,可以实现快速反馈。
    通过此文件,只要报告间隔平均保持不变,端点就可以调整RTCP报告间隔,以便早于下一个计划的RTCP报告发送报告。此外,它还定义了一套错误恢复反馈消息,包括否定确认(NACK),图像丢失指示(PLI),切片丢失指示(SLI)和参考图像选择指示(RPSI)。

    WebRTC 能做什么

    1. WebRTC实现了基于网页的视频会议,标准是WHATWG 协议,目的是通过浏览器提供简单的javascript就可以达到实时通讯(Real-Time Communications (RTC))能力。
    2. WebRTC(Web Real-Time Communication)项目的最终目的主要是让Web开发者能够基于浏览器(Chrome\FireFox…)轻易快捷开发出丰富的实时多媒体应用,而无需下载安装任何插件,Web开发者也无需关注多媒体的数字信号处理过程,只需编写简单的Javascript程序即可实现,W3C等组织正在制定Javascript 标准API,目前是WebRTC 1.0版本,Draft状态;另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台,形成开发者与浏览器厂商良好的生态环境。同时,Google也希望和致力于让WebRTC的技术成为HTML5标准之一,可见Google布局之深远。
    3. WebRTC提供了视频会议的核心技术,包括音视频的采集、编解码、网络传输、显示等功能,并且还支持跨平台:windows,linux,mac,android。

    WebRTC 架构组件简介

    1. Your Web App

    Web开发者开发的程序,Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。

    2. Web API

    面向第三方开发者的WebRTC标准API(Javascript),使开发者能够容易地开发出类似于网络视频聊天的web应用。这些API可分成Network Stream API、 RTCPeerConnection、Peer-to-peer Data API三类。

    Network Stream API
    MediaStream:MediaStream用来表示一个媒体数据流。
    MediaStreamTrack在浏览器中表示一个媒体源。
    RTCPeerConnection
    RTCPeerConnection: 一个RTCPeerConnection对象允许用户在两个浏览器之间直接通讯。
    RTCIceCandidate :表示一个ICE协议的候选者。
    RTCIceServer:表示一个ICE Server。
    Peer-to-peer Data API
    DataChannel:数据通道( DataChannel)接口表示一个在两个节点之间的双向的数据通道 。

    3. WebRTC Native C++ API

    本地C++ API层,使浏览器厂商容易实现WebRTC标准的Web API,抽象地对数字信号过程进行处理。

    4.Transport / Session(传输/会话层)

    会话层组件采用了libjingle库的部分组件实现,无须使用xmpp/jingle协议

    • RTP Stack协议栈
      Real Time Protocol
    • STUN/ICE
      可以通过STUN和ICE组件来建立不同类型网络间的呼叫连接。
    • Session Management
      一个抽象的会话层,提供会话建立和管理功能。该层协议留给应用开发者自定义实现。

    5.VoiceEngine

    音频引擎是包含一系列音频多媒体处理的框架,包括从视频采集卡到网络传输端等整个解决方案。
    PS:VoiceEngine是WebRTC极具价值的技术之一,是Google收购GIPS公司后开源的。在VoIP上,技术业界领先,后面的文章会详细了解

    • iSAC
      Internet Speech Audio Codec
      针对VoIP和音频流的宽带和超宽带音频编解码器,是WebRTC音频引擎的默认的编解码器
      采样频率:16khz,24khz,32khz;(默认为16khz)
      自适应速率为10kbit/s ~ 52kbit/s;
      自适应包大小:30~60ms;
      算法延时:frame + 3ms
    • iLBC
      Internet Low Bitrate Codec
      VoIP音频流的窄带语音编解码器
      采样频率:8khz;
      20ms帧比特率为15.2kbps
      30ms帧比特率为13.33kbps
      标准由IETF RFC3951和RFC3952定义
    • NetEQ for Voice
      针对音频软件实现的语音信号处理元件
      NetEQ算法:自适应抖动控制算法以及语音包丢失隐藏算法。使其能够快速且高解析度地适应不断变化的网络环境,确保音质优美且缓冲延迟最小。
      是GIPS公司独步天下的技术,能够有效的处理由于网络抖动和语音包丢失时候对语音质量产生的影响。
      PS:NetEQ 也是WebRTC中一个极具价值的技术,对于提高VoIP质量有明显效果,加以AEC\NR\AGC等模块集成使用,效果更好。
    • Acoustic Echo Canceler (AEC)
      回声消除器是一个基于软件的信号处理元件,能实时的去除mic采集到的回声。
    • Noise Reduction (NR)
      噪声抑制也是一个基于软件的信号处理元件,用于消除与相关VoIP的某些类型的背景噪声(嘶嘶声,风扇噪音等等… …)

    6.VideoEngine

    WebRTC视频处理引擎
    VideoEngine是包含一系列视频处理的整体框架,从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。

    • VP8
      视频图像编解码器,是WebRTC视频引擎的默认的编解码器
      VP8适合实时通信应用场景,因为它主要是针对低延时而设计的编解码器。
      PS:VPx编解码器是Google收购ON2公司后开源的,VPx现在是WebM项目的一部分,而WebM项目是Google致力于推动的HTML5标准之一
    • Video Jitter Buffer
      视频抖动缓冲器,可以降低由于视频抖动和视频信息包丢失带来的不良影响。
    • Image enhancements
      图像质量增强模块
      对网络摄像头采集到的图像进行处理,包括明暗度检测、颜色增强、降噪处理等功能,用来提升视频质量。

    7.视频

    WebRTC的视频部分,包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。

    • 视频采集—video_capture
      源代码在webrtc\modules\video_capture\main目录下,包含接口和各个平台的源代码。
      在windows平台上,WebRTC采用的是dshow技术,来实现枚举视频的设备信息和视频数据的采集,这意味着可以支持大多数的视频采集设备;对那些需要单独驱动程序的视频采集卡(比如海康高清卡)就无能为力了。
      视频采集支持多种媒体类型,比如I420、YUY2、RGB、UYUY等,并可以进行帧大小和帧率控制。
    • 视频编解码—video_coding
      源代码在webrtc\modules\video_coding目录下。
      WebRTC采用I420/VP8编解码技术。VP8是google收购ON2后的开源实现,并且也用在WebM项目中。VP8能以更少的数据提供更高质量的视频,特别适合视频会议这样的需求。
      视频加密–video_engine_encryption
      视频加密是WebRTC的video_engine一部分,相当于视频应用层面的功能,给点对点的视频双方提供了数据上的安全保证,可以防止在Web上视频数据的泄漏。
      视频加密在发送端和接收端进行加解密视频数据,密钥由视频双方协商,代价是会影响视频数据处理的性能;也可以不使用视频加密功能,这样在性能上会好些。
      视频加密的数据源可能是原始的数据流,也可能是编码后的数据流。估计是编码后的数据流,这样加密代价会小一些,需要进一步研究。
    • 视频媒体文件–media_file
      源代码在webrtc\modules\media_file目录下。
      该功能是可以用本地文件作为视频源,有点类似虚拟摄像头的功能;支持的格式有Avi。
      另外,WebRTC还可以录制音视频到本地文件,比较实用的功能。
      视频图像处理–video_processing
      源代码在webrtc\modules\video_processing目录下。
      视频图像处理针对每一帧的图像进行处理,包括明暗度检测、颜色增强、降噪处理等功能,用来提升视频质量。
    • 视频显示–video_render
      源代码在webrtc\modules\video_render目录下。
      在windows平台,WebRTC采用direct3d9和directdraw的方式来显示视频,只能这样,必须这样。
    • 网络传输与流控
      对于网络视频来讲,数据的传输与控制是核心价值。WebRTC采用的是成熟的RTP/RTCP技术。

    8.音频

    WebRTC的音频部分,包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。

    • 音频设备—audio_device
      源代码在webrtc\modules\audio_device\main目录下,包含接口和各个平台的源代码。
      在windows平台上,WebRTC采用的是Windows Core Audio和Windows Wave技术来管理音频设备,还提供了一个混音管理器。
      利用音频设备,可以实现声音输出,音量控制等功能。
    • 音频编解码—audio_coding
      源代码在webrtc\modules\audio_coding目录下。
      WebRTC采用iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术。
      WebRTC还提供NetEQ功能—抖动缓冲器及丢包补偿模块,能够提高音质,并把延迟减至最小。
      另外一个核心功能是基于语音会议的混音处理。
      声音加密–voice_engine_encryption
      和视频一样,WebRTC也提供声音加密功能。
    • 声音文件
      该功能是可以用本地文件作为音频源,支持的格式有Pcm和Wav。
      同样,WebRTC也可以录制音频到本地文件。
    • 声音处理–audio_processing
      源代码在webrtc\modules\audio_processing目录下。
      声音处理针对音频数据进行处理,包括回声消除(AEC)、AECM(AEC Mobile)、自动增益(AGC)、降噪(NS)、静音检测(VAD)处理等功能,用来提升声音质量。
    • 网络传输与流控
      和视频一样,WebRTC采用的是成熟的RTP/RTCP技术。

    WebRTC 支持的浏览器

    WebRTC在以下浏览器版本中开始支持。

    • 桌上PC端
      Google Chrome23
      Mozilla Firefox22
      Opera18
      Safari11(仍处于开发者预览阶段)
    • Android端
      Google Chrome 28(从版本29开始默认开启)
      Mozilla Firefox 24
      Opera Mobile 12
    • IOS端
      iOS 11
    • 其他平台
      Google Chrome OS
      Firefox OS
      Blackberry 10 内置浏览器

    WebRTC 学习资料

    WebRTC入门

    1. WebRTC架构

    1.1 基本的三角形WebRTC架构

    在这个架构中,移动电话用“浏览器M”表示,笔记本电脑用“浏览器L”表示,通过Web服务器将它们连接起来。要建立一个实时媒体通讯,两台设备需要了解彼此的媒体功能,通过交换呼叫信令控制协议实现。

    诸如这样的信令协议在WebRTC标准中并非事先规定,而是由开发者自行制定。在浏览器RTC会话的步骤如下:

    1. 首先,两个浏览器都从Web服务器下载了WebRTC程序(HTML5/JavaScript);
    2. 其次,两个浏览器通过Web服务器交换控制信令信息(使用嵌入式信令服务器),建立媒体功能功能互通。
    3. 最后,两个浏览器直接建立RTC媒体的音频、视频和数据通道。

    1.2 真正实用的基于P2P的WebRTC架构

    WebRTC使用P2P媒体流,音频、视频和数据的连接直接通过浏览器实现。但是,浏览器却隐藏在NAT(网络地址翻译)和防火墙的后面,这增加了建立P2P媒体会话的难度。这些流程和协议,如ICE或Trickle ICE,STUN和TURN,在建立P2P媒体流都是必不可少的。


    如何使用STUN协议建立一个P2P RTC媒体(如图5所示),简化版的ICE流程如下:

    1. 两个浏览器通过自己的公网IP地址,使用STUN协议信息和STUN服务器建立联系;
    2. 两个浏览器通过SDP提供/应答机制,使用呼叫控制信令消息交换它们已发现的公共IP地址(ICE候选);
    3. 两个浏览器执行连接检查(ICE冲孔),确保P2P可以连接;
    4. 建立连接后,RTC媒体会话和媒体交换就可以实现了。
    5. 但是,假如在一个高度限制的NAT或防火墙,这种直接的路径将无法建立,只能到达TURN服务器。结果是媒体通过TURN服务器分程传递(如下图所示)。

    2. WebRTC协议栈

    参考资料:

    1. https://yunxin.163.com/blog/52im-18/
    2. https://webrtc.org.cn/srtp/
    展开全文
  • WebRTC是什么

    2018-08-23 14:23:07
    作者:ancientcc ...来源:知乎 著作权归作者所有。商业转载请联系作者...首先补充你的一句话,WebRTC的Native Code部分早就可以用在iphone,而且支持得很好,像硬编码、硬解码H264都是运行得很好了。 webrtc是不是...

    作者:ancientcc
    链接:https://www.zhihu.com/question/22301898/answer/145669695
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
     

    首先补充你的一句话,WebRTC的Native Code部分早就可以用在iphone,而且支持得很好,像硬编码、硬解码H264都是运行得很好了。

    webrtc是不是有前途,对所在行业来说肯定有前途。它成为标准不是新闻,不成为标准才是新闻。但如果你不是C/C++开发者,前途指的对个人职业规化啥的,对你来说现在是不是机会?或许真要考虑下。我从三个方面分析。

    一、web浏览器
    Webrtc使web浏览器通过简单的JavaScript api接口实现实时通信功能。在这方面基本已成事实上标准,正如上面写的,它成为标准不是新闻,不成为标准才是新闻。国内就有不少从事和webrtc相关的开发者,像有的公司就基于Webrtc包做些修改、然后给其它开发者用、号称是视频聊天SDK。这样公司好多,但真正做大却有点难。我想有两个原因:JavaScript的限制,浏览器的限制。

    JavaScript的限制。JavaScript是脚本语言,能有什么功能取决于实现它的虚拟机,也就是浏览器这个应用程序。由于受限,问题来了,人民群众的需求总是琳琅满目,你都能提供吗?举个例子,要让对方的头上自动加顶红帽子,——当然,修改浏览器代码让加个帽子不是难事,可谁又知道接下会发生什么,难道要一个改一个?聊天往往是娱乐,娱乐经常是没啥规矩。由于这限制,开发者用它时会有这看法:东西是很好,但总是有那么点不足,而且即使是努力了也不可能解决(自个写浏览器除外)。

    浏览器的限制。这就要涉及到聊天场景。很现实问题,如果我想和你聊天,身边有手机,你认为会用浏览器吗?对PC,网页比app方便,而移动设备却有点反着来,而且将来移动设备会越来越多。关于这个再深入个问题:如果PC用浏览器,手机用app,聊天是否可行?技术实现上没问题,可事实上基本不会做,代价太高划不来。浏览器时,信令走的是Websocket,app用Websocket纯粹是没事找抽,直接C Socket既简单又高效。浏览器时,两socket间没啥心跳包机制,app时心跳包机制可很大提升效率。浏览器时,由于用JavaScript开发,功能受限,app时用Native Code,自个想要什么就能实现什么。而且,Webrtc是跨平台包,基于C/C++的跨平台SDK也不是没有,何不在开发时顺便开发出个Windows平台app。以上导致了app不太可能和网页聊天,这又让浏览器少去很多应用场景。

    综合来说,在浏览器不是webrtc不行,而是其它原因导致有那么点尴尬。想做一个“完美”用户体验的聊天工具,终归还得用app。这就是接下要说,webrtc中的Native Code部分。

    二、webrtc中的Native Code部分
    Webrtc分两层,底层是个用C++写的库(Native Code),然后上层写个Javascript封装,以便供HTML5调用。既然是写app,那完全不用管上层Js封装,而且Google在开发Webrtc时已考虑用在app,底层C++库的API已做得很完善了。也就是说,一旦直接用Native Code,完全和浏览器无关了,作为C/C++开发者,他就可以用webrtc去实现自个想实现的所有东西。

    Native Code摆脱了哪些限制?可参考这个问题贴,可以用WebRTC来做视频直播吗? - HTML5 - 知乎。用浏览器,就是p2p聊天都功能受限,更别说去实现直播。而实际中基于浏览器的直播也不推荐用webrtc技术。这里重复抄下我在那问题回的一段话。

    为什么强烈建议你基于webrtc?对直播系统,难的不是服务器,而是客户端。客户端难的地方则主要体现在两个方面,一是网络传输相关,像穿透,二是流数据相关,像编码、解码。而这些正是webrtc帮你解决了。也正因为如此,现在很多直播系统最早的客户端其实是以webrtc为根的,只是后面自个不断优化,慢慢地变成自个系统而已。——诚然,官方webrtc是有地方不尽如意,但它们不断更新,就像最近一段时间优化了回音消除。

    如果你熟悉C/C++,又刚好从事和网络视频相关行业,强烈建议你学习Webrtc。如果你不从事网络视频相关行业,却是C/C++开发者,那还是强烈建议你学习Webrtc,原因是接下要说的Webrtc代码的C/C++价值。

    三、Webrtc代码的C/C++价值
    最近回答了这个问题,怎么样才算是精通 C++? - 编程 - 知乎。在那里建议学习C/C++是两个步骤,知道基本语法后就到网上找开源项目,多看看、多调试前辈们代码。我推荐的开源项目就是Google的Webrtc。

    虽然Webrtc的代码量很大,但看的目的不是要全看懂,只是看你想看的部分。语法上,Webrtc用了最新C/C++语法,像std::unique_ptr,Webrtc是视频聊天基础库,众多知名浏览器都是基于它实现视频聊天。扩展专业知识上,Webrtc为完成聊天涉及到很多方面,像网络穿透,视、音频编码解码,采集摄像头、卖克风,截屏。C/C++编程技能积累上,Webrtc能让你直接基于它的一些模块写代码,像多线程同步模块(https://zhuanlan.zhihu.com/p/25147311?refer=c_75458601),网络收发模块。获取更多开源项目上,Webrtc像手心,基于它你会涉及到很多开源项目,像用于加密、解密、网络安全的boringssl,数字编解码的ffmpeg,libvpx,等等。活跃度上,Webrtc是Google底下团队维护的项目,基本做到一个月一小变,不仅能让你获得那些专业的最新技术,还能学习最新C/C++语法。还有很重要的是,Webrtc代码是跨平台的,完全支持当前主流操作系统,像Windows、iOS、Android、Mac OS X、Linux,到时你会发现,C/C++是种多么好的跨平台语言。

    一句话,Webrtc非常值得深入,甚至认为可以进入大学课程。


    作者:网易云信
    链接:https://www.zhihu.com/question/22301898/answer/439523681
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
     

    WebRTC是什么?

    首先解释一下WebRTC并非是一个“拿来即用”的“端到端”开源解决方案,如果你以为只需要在web端写几行JavaScript就可以实现浏览器之间的音视频通信,那可能会失望。

    但事实上WebRTC能给人更多惊喜,他既不是“解决方案”,也不是某种代码库。

    WebRTC是终端的音视频媒体访问接口在类似于web环节下的标准化抽象。是对于实时音视频通话建立过程,编码格式,传输方式等等的规范。

    所以不要被“Web”之名影响,无论具体如何实现,只要符合标准规范就可以获得实时的通信能力,这才是WebRTC的意义所在。

    WebRTC的潜力在哪里?

    聊聊这套标准的潜力,事实上WebRTC是不受限于Native App或者浏览器终端运行环境的。Browser、desktop App、Android、iOS、IoT都可以,你只要IP连接且符合规范就可以互通。

    这意味着什么?这意味着无数智能终端产品或者运行在智能终端上的app的实时通信能力的大门彻底打开。举个例子,云信最近帮助步步高小天才手表做的手表实时通信,帮助家长和小朋友实现沟通,而且你不用买苹果表……

    再扩大一下想象空间:在线课堂、视频会议、视频社交、远程协助都可以扩展更大的使用场景。

    在WebRTC问世之前,并么有一个统一的标准来描述设备的实时通信能力与连接过程,大家都是各做各的,各用各的。但是音视频通信研发是即时通信领域里面的最hard模式,没有大量基建投入和研发资源投入,基本不能成行。WebRTC的最大优势就在于“标准”,通信终端只要符合标准就可以用同一种“语言”交谈。目前各大浏览器厂商都积极参与到WebRTC技术的生态中,从web应用开始,WebRTC将成为基于网页的音视频实时通信技术规范。之后,在Web应用于移动终端应用的交互需求驱动下,越来越多的移动应用的音视频服务也将采用WebRTC的技术规范。这套标准激活的是人与人,物与物之间信息互联,也就意味着这是全新应用场景的底层技术保障。

    今年年初流行的直播竞答,抓娃娃机(远程信令控制),在线教育大力发展和实时音视频技术发展起了相辅相成的作用。

    编辑于 2018-07-11

    展开全文
  • WebRTC

    2019-06-01 21:41:13
    WebRTC,名称源自网页即时通信(英语:Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C...

    1.官网:https://webrtc.org/

    2.简介:

    WebRTC,名称源自网页即时通信(英语:Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。

    支持浏览器:

    3.通话模型

    • P2P 通话的网络模型

    可直接通过 P2P 互相交换数据。如果由于某些网络环境原因,无法成功打通 P2P 连接的话,则可以通过一台 TURN Server 来中转数据。受带宽的限制,尤其是上行带宽,适用于3方通信一下的场景。

    • SFU 通话的网络模型

    Selective Forwarding Unit,类似发布订阅模式。通过服务器来路由和转发 WebRTC 客户端音视频数据流。

    • MCU通话的网络模型

    Multipoint Control Unit,

    4.资料

    WebRTC视频通话中最多能容纳多少用户? https://www.jianshu.com/p/9ef708f93499
    多媒体开发 https://www.jianshu.com/c/e5b30935c054
    WebRTC中文网 https://webrtc.org.cn
    WebRTC官网 https://webrtc.org/
    WebRTC范例 https://webrtc.github.io/samples/

     

    展开全文
  • RTC与WebRTC有什么区别

    2017-11-21 11:03:36
    RTC(Real-time Communications),实时...但是,很多开发者对一些概念还是有混淆的,比如RTC与WebRTC,RTC与直播,RTC与IM。   一、RTC和WebRTC有什么区别?   实时通信(RTC)最容易和WebRTC混淆,实
  • 什么是WebRTC2. WebRTC框架介绍详细组件介绍3. 模块细致讲解国内方案厂商WebRTC发展前景文章借鉴: 1. 什么是WebRTC WebRTC,名称源自网页即时通信(英语:Web Real-Time Communication)的缩写,是一个支持网页...
  • webrtc详细介绍

    2017-09-19 10:58:12
    Browser Networking》w3c webrtc文档web层主要接口: MediaStream: 采集音视频 RTCPeerConnection: 传输音视频 RTCDataChannel: 传输自定义数据前言一大段废话,强调了一下webrtc使用的udp,但不是普通的ud
  • WebRTC -- 认识WebRTC

    2018-11-25 17:05:45
    WebRTC (Web Real-Time Communications) 是一项实时通讯技术,它允许网络应用或者站点,在不借助中间媒介的情况下,建立浏览器之间点对点(Peer-to-Peer)的连接,实现视频流和(或)音频流或者其他任意数据的传输...
  • 本教程主要以WebRTC JavaScript API为例,使用WebRTC实现实时通信 1. 介绍WebRTC整体架构,WebRTC JavaScript API 2. 如何获取webcam摄像头音视频数据 3. WebRTC peer之间建联流程 4. 介绍WebRTC信令,...
  • 什么是webrtcwebrtc的来历。2.webrtc只能用于浏览器么?3.学习webrtc的难点:4.如何学习webrtc?5.学习计划:掌握:技术: 写在最前面的话 根据项目需求,最近开始学习webrtc,这块内容起点较高,比较庞杂,需要一...
  • WebRTC-线程模型(1)

    2017-11-23 14:12:23
    在介绍WebRTC的线程模型之前,先介绍webrtc线程模型中用到的几个简单、常用的模块或函数。webrtc是一个代码宝库,且它本身跨平台(windows,linux,ios,android),不管是哪个平台上面开发,都可以从中学习到很多...
  • WebRTC--rtc_base库移植

    2017-12-24 21:42:26
    rtc_base是webrtc的基础库,也是一个不可多得的跨平台的基础库,它提供了线程、网络、指针等多个方面的支持。 我们可以将它单独提取出来加以改造,然后使用。 rtc_base库位于src\rtc_base文件夹中。 我们将其移到...
  • WebRTC架构图说明

    2020-07-19 21:40:59
    首先我们通过webRTC官网上的一张图了解一下webRTC的架构: 网上也有很多资料说这张图在webRTC的官网上,但是很多童鞋根本就找不到。这是因为很多童鞋没有进行科学上网: WebRTC架构说明英文文档:...
  • learning webrtc 中文版

    2020-07-30 23:32:03
    WebRTC 是一个支持网络浏览器进行实时语音对话或视频对话的软件架构。, 《Learning WebRTC 中文版》使用形象的案例介绍,逐步深入地阐述了WebRTC 的幕后工作原理。通过阅读本书,读者可以快速、有效地掌握创建一个...
1 2 3 4 5 ... 20
收藏数 15,774
精华内容 6,309
关键字:

webrtc