webrtc

最近我们的各个产品都在整合国标GB28181的功能扩展，有EasyNVR的国标GB28181向上级联、有EasyGBS的下级接入与对上级联、有EasyCVR的多协议接入与GB28181输出，大家都在做GB28181，国标的成熟与兴起是政策与执行相互促进推动的结果，以前没有一个这么完善的协议能统一平台相互级联的思路，如今有了，那么各种类型的系统支持GB28181就是必然的； EasyNVR将RTSP/Onvif设备汇聚并向上级平台级联： EasyGBS国标接入与向上级联： EasyCVR能将各种协议汇聚并向上GB28181级联： 同时，我们也有在做WebRTC的更底层的开拓，发现WebRTC的实时性效果确实是出奇的好，我们综合分析了一下： WebRTC的视频传输采用的是RTP/RTCP协议，与GB/T28181一样； WebRTC在信令上各有各的自定义交换方式，与SIP协议类似，其主要目的就是做SDP等信息交换； 如果能衔接WebRTC的信令交换方式与国标SIP的信令交换方式，那WebRTC的RTP/RTCP是不是就可以与GB/T28181的RTP/RTCP贯通？ 那么GB/T28181是不是就可以借助到WebRTC的各种底层框架优势？ WebRTC+GB28181，延时、对讲、回音，是不是统统都没问题了？ 是的，我们正在按照这个思路在开发！ 来源： oschina 链接：

最近我们的各个产品都在整合国标GB28181的功能扩展，有EasyNVR的国标GB28181向上级联、有EasyGBS的下级接入与对上级联、有EasyCVR的多协议接入与GB28181输出，大家都在做GB28181，国标的成熟与兴起是政策与执行相互促进推动的结果，以前没有一个这么完善的协议能统一平台相互级联的思路，如今有了，那么各种类型的系统支持GB28181就是必然的； EasyNVR将RTSP/Onvif设备汇聚并向上级平台级联： EasyGBS国标接入与向上级联： EasyCVR能将各种协议汇聚并向上GB28181级联： 同时，我们也有在做WebRTC的更底层的开拓，发现WebRTC的实时性效果确实是出奇的好，我们综合分析了一下： WebRTC的视频传输采用的是RTP/RTCP协议，与GB/T28181一样； WebRTC在信令上各有各的自定义交换方式，与SIP协议类似，其主要目的就是做SDP等信息交换； 如果能衔接WebRTC的信令交换方式与国标SIP的信令交换方式，那WebRTC的RTP/RTCP是不是就可以与GB/T28181的RTP/RTCP贯通？ 那么GB/T28181是不是就可以借助到WebRTC的各种底层框架优势？ WebRTC+GB28181，延时、对讲、回音，是不是统统都没问题了？ 是的，我们正在按照这个思路在开发！ 来源： oschina 链接：

随着实时音视频通信技术的发展，1对1，1对多直播等在线教育形式不断的满足个人定制化的学习需求。掌门1对1音视频负责人 曾小伟在LiveVideoStack 线上交流分享中介绍了在线教育中音视频技术的应用现状、挑战以及未来的发展。本文由LiveVideoStack整理而成。 文 / 曾小伟 整理 / LiveVideoStack 直播回放 https://www.baijiayun.com/web/playback/index?classid=18120589731745&token=Y70ES34BeD3hKKZLIMQ5htJW7QTXpNFvF3HfaEnKnKsX8VWf2DfBnRl2q5tNi5GNCqdH1zJ1Si0 大家好，我是来自掌门1对1的曾小伟，本次跟大家分享一下在线教育领域音视频技术的探索与应用，分享内容主要分为以下四个部分： 1，在线教育场景剖析； 2，在线教育中音视频技术应用的现状及难点； 3，在线教育领域音视频技术的发展； 4，总结； 一，在线教育场景剖析 1. 1v1教学 首先为大家介绍的在线教育场景是“1对1”教学，上图是掌门1对1官网的一幅宣传图，它讲的是一个1对1教学的场景，就是一个老师和一个学生在一起上课的情景。我们将图中的场景进行了分析简化。 从简化过的图中可以看出，1对1教学时，上课的主角就是学生和老师

前段时间我们讲到我们正在开发的WebRTC项目，在WebRTC项目中，我们也遇到了很多困难，比如在封装js库的时候难免会碰到this执行的问题，这样会导致Cannot read property “xxxxx” of null，或者找不到方法， 如下图： 分析问题 this的指向在函数定义的时候是确定不了的，只有函数执行的时候才能确定this到底指向谁，实际上this最终指向的是那个调用它的对象。那么本案例中造成这个问题的原因大致有一下三种： 1、this的执行问题，导致未初始化方法 2、使用对象改变了this的指向 3、本来就无这个方法，所以无法使用 解决问题 自身代码如下图： 运行效果如下，本来想指向自身的方法，但是多了个_device对象： 要解决上述问题必须要改变this的指向，该问题的关键在于重新创建了对象，因此最终我们决定使用bind来改变指向，如下图： bind方法主要就是改变函数绑定到某个对象从而改变指向问题，于是该问题得以解决。 我们的开发目前在紧锣密鼓的进行当中，未来的发展方向将会有两个，一个是通过WebRTC技术优化我们已经开发的视频平台EasyNVR、EasyGBS、EasyCVR等，另一个是开创新的基于WebRTC做传输的视频服务。 如果大家想了解一些关于我们现有视频平台的相关内容，也可以联系我们，经过实践测试，包括EasyCVR、EasyNVR

前段时间我们讲到我们正在开发的WebRTC项目，在WebRTC项目中，我们也遇到了很多困难，比如在封装js库的时候难免会碰到this执行的问题，这样会导致Cannot read property “xxxxx” of null，或者找不到方法， 如下图： 分析问题 this的指向在函数定义的时候是确定不了的，只有函数执行的时候才能确定this到底指向谁，实际上this最终指向的是那个调用它的对象。那么本案例中造成这个问题的原因大致有一下三种： 1、this的执行问题，导致未初始化方法 2、使用对象改变了this的指向 3、本来就无这个方法，所以无法使用 解决问题 自身代码如下图： 运行效果如下，本来想指向自身的方法，但是多了个_device对象： 要解决上述问题必须要改变this的指向，该问题的关键在于重新创建了对象，因此最终我们决定使用bind来改变指向，如下图： bind方法主要就是改变函数绑定到某个对象从而改变指向问题，于是该问题得以解决。 我们的开发目前在紧锣密鼓的进行当中，未来的发展方向将会有两个，一个是通过WebRTC技术优化我们已经开发的视频平台EasyNVR、EasyGBS、EasyCVR等，另一个是开创新的基于WebRTC做传输的视频服务。 如果大家想了解一些关于我们现有视频平台的相关内容，也可以联系我们，经过实践测试，包括EasyCVR、EasyNVR

淘宝直播最近连续三年直播引导成交大幅增长，2020年以来，有100多种职业转战淘宝直播间，无论达人身份还是商家身份，都在新风口的驱动下大量入场。如何应对双十一这种高峰值用户直播需求，这无疑对淘宝直播提出了更高的技术要求和挑战。同时，电商直播有强互动诉求，主播对弹幕的回复越及时，对购买越有促进效果。 通过AB测试验证，延时对电商直播GMV有正向作用。但常规的HLS、FLV、RTMP等直播格式延时很难再降低，常规直播CDN也已经不再适合更低延时的直播，整个技术体系需要升级。为了降低直播延时，行业上有几种做法： 方案对比 私有协议 TCP协议栈优化 QUIC SRT WEBRTC 效果 最好 一般 较好 较好 好 通用性 差 最佳 佳 较低 良 实现难度 难 可深可浅 一般 一般 难 LHLS、CMAF甚至LLHLS方案的延时，基本都会超过2秒，暂不做比较。综合考虑，WEBRTC方案相对符合我们的需求。淘系技术部跟阿里云一起共建了一张基于WEBRTC低延时多媒体传输网。 通信、直播二网合一的低延时传输网 直播的延时始终是个老大难问题，很多团队都在考虑怎么降低延迟。低延迟传输是一个综合性的问题，要从整体入手，不仅要从设计上考虑，还需要客户端，服务器，数据系统紧密配合。最根本的传输协议不升级，延迟始终有一个天花板。 RTCP协议头 对于传统的rtmp，hls，http

原文链接： https://mp.weixin.qq.com/s/RCefMEXY-lx7RTu0zq5LLw 实时音视频的开发学习有很多可以参考的开源项目。一个实时音视频应用共包括几个环节：采集、编码、前后处理、传输、解码、缓冲、渲染等很多环节。每一个细分环节，还有更细分的技术模块。比如，前后处理环节有美颜、滤镜、回声消除、噪声抑制等，采集有麦克风阵列等，编解码有VP8、VP9、H.264、H.265等。 我们今天汇总了一些能帮助到正在学习或进行音视频开发的实时音视频开发者们的开源项目与几个也在为开源社区贡献力量的商业服务。这些项目分为几类：音视频编解码类、视频前后处理、服务端类等。 音视频编解码类开源项目 视频编解码的作用，就是在设备的摄像头采集画面和前处理后，将图像进行压缩，进行数字编码，用于传输。编解码器的优劣基本在于：压缩效率的高低，速度和功耗。 目前，主流的视频编码器分为3个系列：VPx（VP8，VP9），H.26x（H.264，H.265），AVS（AVS1.0，AVS2.0）。VPx系列是由Google开源的视频编解码标准。在保证相同质量情况下，VP9相比VP8码率减少约50%。H.26x系列在硬件支持上比较广泛，H.265的编码效率能比上一代提高了30-50%，但是复杂度和功耗会比上一代大很多，所以纯软件编码实现的话有一定瓶颈，现有的技术下