TSINGSEE青犀视频官方技术博客

在EasyRTC中，已实现会议室合流转推到流媒体内核进行转发并生成录像保存到服务器，用户可以根据日期查询该录像并进行播放、下载。

EasyRTC平台是基于当下主流的WebRTC框架构建而成的音视频服务平台，依托语音、视频、广播、会议、对讲、GIS等技术，提供全平台互通高品质实时视频通话功能，用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。

在EasyRTC中创建会议室，用户可进入会议室进行音视频通信。因此新建会议室后，后端会返回一个该会议室的RTMP推流地址，在RTC通信时将视频信息推到此地址，实现视频会议的分发、保存录像等各种功能。

EasyRTC适合召开各种现场会议，实现多个会议现场之间的视频多画面轮换，支持即时会议、例会、多组会议等会议形式，并可将视频会议以图文+视频+现场声音实时直播的形式通过互联网对外直播，实现PC、手机、网页全覆盖，扩大直播观看的范围。更多关于EasyRTC的功能与开发，敬请关注我们的更新。

在两个用户通信前，首先会向公网的 stun 服务发送请求，获取自己的公网地址，然后通过服务器将各自的公网地址转发给对方，这样双方就知道了对方的公网地址。根据这个公网地址就可以直接通信。

众所周知，WebRTC技术使用架构是点对点的（浏览器之间的）通信，用户无需安装任何第三方插件，使得自己和对端进行通信，这也是其非常强大的一个优势。

WebRTC的存在给在线视频会议系统带来了新的模式，TSINGSEE青犀视频开发的网页视频会议系统EasyRTC综合了webrtc和rtmp/rtsp方案的优点，支持一对一、一对多等视频会议互动通话，满足语音社交、在线教育和培训、视频会议和远程医疗等场景，新的EasyRTC项目也即将和大家见面。在测试 EasyRTC 新版的点对点通话功能时，出现报错：Failed to execute ‘send’ on ‘RTCDataChannel’: RTCDataChannel.readyState is

上一篇我们介绍了开发Webrtc建立P2P的流程，根据该流程，我们进行了实际操作，但是在Webrtc P2P连接中，浏览器控制台出现错误信息：发起端出现错误如下：“DOMException: Failed to execute ‘setRemoteDescription’ on ‘RTCPeerConnection’: Failed to parse SessionDescription.”；接收端出现错误如下：“DOMException: Failed to execute ‘addIceCand

目前EasyGBS平台已经支持Webrtc协议的视频流输出了，对我们来说是一个很大的进步。webrtc及时性、低延时的优势可以让视频输出行业达到一个新高度，本文我们主要是和大家分享一下开发过程中webrtc建立P2P的流程，流程主要分为两个部分，一个是发起端，一个是接收端，下面就这两个部分的运行详细讲解一下。发起端a、发起端创建websocket长连接。b、创建PeerConnection对象，并主要监听onicecandiate、addstream和onconnectionstatechan

自从RTMP推流协议诞生以来，依靠RTMP协议做的推流开发就一直都未停歇，在没有找到更加完善的替代品前，市面的主流推流仍将会由RTMP协议来实现。如大众所熟知的一样，PC端web主流的视频直播方案也一直是RTMP，包括我们开发的EasyCVR平台，也在最新的版本中支持RTMP推流了，不过该版本目前正在测试当中，测试完毕将会上线，大家届时可以关注。我们本文的焦点还是放在HTML5视频的推流直播上。随着直播平台爆发式的增长，H5直播的需求也变得异常丰富。通过H5直播的整体流程大致分为三个模块：视频采

近期我们在编译WebRTC时碰到了一些问题，通过C++编译WebRTC项目，获取sdp的数据为空。我们使用window api调用go服务端接口，接收到的数据为空。返回的数据如下：通过数据打印出来，发现bufRev没有数据，也没有出现其他错误信息。通过打断点分析发现，异常情况下，select函数一直始终返回0：再到go服务端发现接口已经调用成功：使用上面简单测试go服务器接口（/stream/test/:channel:）。通过这个接口测试，select函数返回的是1，而且可

大家知道我们的WebRTC开发已经到达一个新的阶段了，目前EasyGBS国标视频云服务内已经支持WebRTC协议视频流的输出了，欢迎大家体验。搭建webrtc不得不提的就是turn服务器了，在webrtc中，每当两个设备之间无法直接连接时，就需要一个turn服务器来进行中转，同时，在点对点的服务中，也需要安装并运行turn服务器。但是如果将设备连接到媒体服务器（无论是用于群呼的SFU还是其他类型的服务器），仍然需要一个turn服务器，这又是为什么？实际上，这主要是因为某些防火墙会阻止某些类型的流

做流媒体视频开发的团队都知道，目前很多开发团队的视频流解决方案都喜欢使用 HTTP Live Streaming (HLS) 来直播视频。 我们经常被问到的另一项技术是 WebRTC。 这两种技术都很棒，但应用却截然不同。 在这篇文章中，我们将研究两者的特性和优势，以及它们适合的主要应用场景。什么是HLS？HTTP Live Streaming (HLS) 由 Apple 开发，目前是当今网络上流式传输视频的主要方式。 HLS 名称中的“直播流媒体”有点用词不当，因为视频不需要直播——油管.

WebRTC实现了基于网页的视频会议，标准是WHATWG协议，目的是通过浏览器提供简单的javascript就可以达到实时通讯（Real-Time Communications (RTC)）能力。目前EasyGBS也已经成功接入webrtc视频输出。WebRTC是互联网行业中流媒体技术的集大成者，涵盖了音视频采集、媒体处理、编码、p2p、网络发送到网络接收、解码，普遍用于直播、音视频聊天、视频会议，可以让没有音视频开发经验的人也可以轻松开发音视频通讯软件。传统安防视频监控行业也是基于音视频流媒体技术

在Webrtc的编码中有三种编码方式：VP8、VP9和H264编码，这三种编码大部分浏览器都支持，其中VP8是目前为止浏览器内部使用最多的一个编码方式。浏览器使用的推流编码是VP8，所以传输的是VP8，想要在c++端编码出H264，那要怎么做呢？在编译Webrtc的相关产品中，我们就遇到了此类问题，所以和大家分享一下。webrtc中有一个H264编码文件，在modules/video_coding/codecs/h264/h264_encoder_impl.h。进入该文件分析，有三个函数最为主要

也许大家经常被问到" WebRTC安全吗？"一句话...是的。 WebRTC是安全的，并采取了许多安全措施以确保数据保持安全。这些包括：1.浏览器保护众所周知，WebRTC是在浏览器之间直接制定的，无需插件。这使WebRTC本质上更安全，因为它提供了额外的保护级别，可抵御可能伪装成插件的恶意软件或其他不良软件安装。此外，由于WebRTC是作为浏览器的一部分提供的，因此倾向于通过浏览器供应商的自动更新来快速解决任何潜在的安全威胁或漏洞。2.媒体访问WebRTC规范通过要求使用摄像机或麦克风的明

在开发webrtc时，由于是新技术，我们在编译或者调用过程中会出现平常不太常见的问题，比如使用js语言调用go接口发送base64，Go程序出现设置webrtc远端会话描述提示，但是控制台会出现报错。Js端出现接口500（Internal Sever Error）错误：js端代码是通过RTCPeerConnection方法来监听onicecandidate里的函数回调的值，如果回调的值未null的话，说明就是监听完成，这里要判断是否为null，再获取本地的会话描述转换base64传给服务端。

我们在通过GO语言开发webrtc服务时，使用js进行摄像头推流调用go服务端http，交换sdp信息，先把摄像头流推到服务端进行webrtc交互，再调用另外go http服务进行拉流。第一次进行http拉流，webrtc 会话描述进行过交换，但是测试期间我们发现，如果此时再打开浏览器进行http 会话描述，go服务端会卡住，导致浏览器等段时间会超时错误。此处的流程应该是下面这样的：1、Go 中webrtc拿到的流会放到一个全局变量中，如下：2、通过go的接口交换会话描述，再使用we

对于WebRTC的研究，TSINGSEE青犀视频已经进入一个更深的阶段，不仅仅满足于播放或者分屏此类功能，还需要视频的连贯、自动刷新等功能。在WebRTC播放器的开发中，我们使用的是js Video标签，在播放WebRTC拉到流时，有大部分几率出现下图状况，图像刷新不出来。在界面中点击开始按钮，流可以播放出来。但是在代码添加video.onloadedmetadata方法，里面写入video.load()和video.play()函数，再多次刷新页面也会出现视频没有刷新出来的情况。这

什么是WebRTC？Web实时通信（WebRTC）既是一个开放源代码项目，也是一个行业标准和规范。它支持在浏览器和设备之间进行本地媒体实时传输，例如语音，视频和数据传输。这使用户能够从其主要的Web浏览器进行通信，而无需复杂的插件或其他硬件。Google于2011年5月首次宣布WebRTC项目，以开发一套通用协议来在浏览器、移动平台和IoT设备中启用高质量RTC应用程序。当时，Flash和插件是提供实时通信的唯一方法。两年后，经过大量工作，Chrome和Firefox之间建立了第一个跨浏览器视频

Web实时通信（WebRTC）最近成为万维网联盟（W3C）的建议和Internet工程任务组（IETF）的标准。 这是WebRTC漫长征途中的一个重要里程碑，WebRTC始于2011年，当时Google开源了关键通信技术，而爱立信则实现了ConnectionPeer API。 随着WebRTC工作组努力整合新的用例（音频和视频提要的实时处理，物联网用例等），新标准将继续发展。Ericsson对采用新标准发表了评论：“在建立人对人通信系统方面有着悠久的历史的爱立信（Ericsson）参与了WebR

在编译WebRTC过程中，我们上一篇解决了c++编译WEBRTC视频播放项目获取sdp会话描述失败的问题，在解决这个问题之后，重新建立SDP会话描述之后，视频添加成功，但是实际播放的时候画面会卡住。测试C++ WebRTC播放时，在播放大约4~6s后，画面会停止播放，一直卡在最后一帧画面。报错如下：(video_receive_stream.cc:659): No decodable frame in 3000 ms, requesting keyframe.该报错的意思是播放画面一段时间，3

近几年随着人们对网页视频要求的提高，WebRTC被越来越多的人熟知，运行WebRTC需要搭建一个用户界面，并且需要一台服务器来发送信令，WebRTC处理SDP信息的创建和处理，通过拉流库进行拉流，实现WebRTC的网页播放功能。我们在通过C编译WebRTC时，出现添加视频未成功的现象。CWebRTC实现与go pion库进行拉流，添加视频和音频源，导致C++中WebRTC为进入自定义的重写的虚函数里，无法进行下一步操作。例如获取SDP会话描述：按照正常的流程建立会话描述，以C++中We.

随着科技的进步和大众对教育的重视，越来越多的创新授课方式被搬进了课堂。除去传统的讲课方式之外，与信息技术结合的授课为改变传统的教学模式提供了有效途径，这其中就包括课堂桌面同屏授课的方式。此前我们开发的一款桌面同屏的软件EasyScreenLive，可以直接运用在课堂同屏当中：简单、高效、稳定的集采集、编码、组播、推流和流媒体RTSP服务于一身的同屏功能组件，具有低延时、高效能、低丢包等特点。目前支持Windows，Android平台。通过EasyScreenLive我们就可以避免接触到稍显复杂

近期我们开始研究通过go来实现webrtc，在使用第三方API进行base64编码加密时，用的是base64.StdEncoding.DecodeString方法来进行解码和base64.StdEncoding.EncodeToString编码，但是最后执行结果会使程序终止。解码如下：程序终止：Base64字符串如下：进行js通过调接口与go服务端通信，再进行js解码并无问题。这就说明应该是go端解码出现错误。通过查阅资料得知，base64.StdEncoding.D

webrtc的优势在于超低延时的直播，在网页直播方面有很高的可用性和发展性。TSINGSEE青犀视频基于webrtc编译的网页播放项目webrtc-client已经完成且后续也在不断优化中。在通过webrtc进行网页播放时，第一次连接正常，可以出现画面和声音；但是服务器关闭，前端重连出现video标签时间进度在跑，但是没有画面的情况。此处我们是先使用webrtc拿到数据流，再用网页的video标签播放。第一次初始化可以播放，说明服务端通过webrtc反馈的数据流没有问题，因此我们判定是js代

通过开发webrtc技术，我们已经实现了网页低延迟的直播，对于WebRTC的开发目前已经完成了大的框架，网页的测试也已经逐步收尾，WebRTC的上线将会给我们的用户带来更好的直播体验。在测试webrtc期间，我们发现使用浏览器打印服务端反馈的数据，是没有音频的，但是使用的本地rtsp流有声音。通过以上截图可以看出服务端反馈只有视频，而浏览器使用的video标签中音频音量也不可点击。这个问题肯定是服务端的问题，服务端没有反馈音频流，浏览器添加不了音频流，只能查看服务端代码在进行分析。分

TSINGSEE青犀视频研发WebRTC的最终目的主要是让大家能够基于浏览器（Chrome\FireFox…）轻易快捷地实现实时多媒体应用，而无需下载安装任何插件，研发中我们也进行了多方面的编译，下面分享一个编译过程中遇到的错误。我们找到一个webrtc的资源，下载并且编译，在执行“./src/build/install-build-deps.sh”时，执行如下错误：ERROR: The installation of the Chrome OS default fonts failed。该

Webrtc作为TSINGSEE青犀视频突破视频直播延时的新方式，我们投入了不少精力对此进行研究，目前的webrtc-client已经初具雏形。在测试过程中，使用webrtc推两路rtsp流，在浏览器可以正常播放，两路流都可以播放；但是假如关闭其中一路的推流，浏览器video标签中所有流的视频画面都会卡住不动，刷新页面也不会出现视频流的id。正常状态下后端应该会返回视频id，即下图中圈出的位置。但在该错误状态下，这个返回数组显示为空。该处连数据都获取不到，因此我们考虑是服务端问题，.

目前RTP或者基于上面的WebRTC直接使用作为直播技术的挑战性非常高，还缺乏成熟的开源工具和生态，但是RTP的低延迟特性使得很多大厂正在进行二次开发。RTP不是不可以作为直播平台的技术选项，只是目前缺乏很好的支持，需要自己进行定制开发的部分较多。作为视频行业的领导者，TSINGSEE青犀视频率先投入研发，尝试编译RTP推流程序。在TSINGSEE青犀视频编译RTP推流程序时，出现以下错误：*const char * 类型的值不能用于初始化 char * 类型的实体。此错误在于类型不匹配导致，针

我们介绍过很多TSINGSEE青犀视频开发团队开发WebRTC的过程，我们使用到了c开发。C不仅拥有计算机高效运行的实用性特征，同时还致力于提高大规模程序的编程质量与程序设计语言的问题描述能力。在开发WebRTC流媒体服务器时，WebRTC推流在使用浏览器拉流一段时间后，c++ 程序会导致崩溃，浏览器拉流端的视频也会停止播放，c++ 推流端在vs2017会进入到错误断点报以下内容：“0xxxxxxx处（位于xxxxx.exe中）有未经处理的异常，异常：nlohmann::detail::type_

我们上一篇说到TSINGSEE青犀视频开发团队已经基本实现了WebRTC的视频推流和播放，还剩一些小问题需要我们优化。我们使用VideoTrackInterfaceInterface类对WebRTC进行编译，在重写的该类时，程序编译崩溃报错：“初始化”：无法从“T *”转换为“T *”; “rtc::scoped_refptr::ptr_”：未能初始化成员。我们双击该错误，定位到了该函数成员rtc::scoped_refptr，而rtc::scoped_refptr类是WebRTC的一个

大家知道我们前期成立了一支小分队专门做WebRTC的研究，经过几个月的攻关，我们也马上要发布我们的RTC整体框架，包括RTC的推流、RTC服务器、RTC播放器等，先可以看一下TSINGSEE的RTC对安防视频流的分发：在我们编译WebRTC过程中，测试使用ffmpeg拉rtsp://的流，获取到H264裸流，进行WebRTC推流会出现丢帧情况；RTP: PT=60: bad cseq 6416 expected=34c8error while decoding MB 61 51, bytes

近期我们拿webrtc实现了部分视频播放及分屏的功能，但是在通过WebRTC实现前端拉流播放的时候，我们看到控制报错’producerId’ of undefined。以下图片是创建一个对等的连接，并通过线程实现推流；CreatePeerConnectionFactory方法创建了一个PeerConnectionFactoryInterface接口的实现对象，这个是webrtc核心协议，但是现实播放的时候却发现前端拉取不到视频流。我们重新检查CreatePeerConnectionFacto