Babosa的专栏

MPP播放标准的音频G711/G726/ADPCM码流时，需要先获取RAW流数据，再根据每帧数据长度per_sample_len添加语音帧头才能播放。最近我们在调试EasyRTC双向通话时（海思设备与浏览器），发现很多对接的开发者不知道怎么用海思SDK去播放浏览器传过来的音频数据；MPP为了兼容上一代芯片，要求在音频裸码流每帧数据前添加语音帧头才能播放。MPP不能直接播放标准的音频G711/G726/ADPCM码流。

1、嵌入式端的资源有限，大部分的嵌入式因为成本敏感的原因，flash总的空间大小控制在16M左右，这就导致每一块的资源用量都是严格要求的，所以，RTC通信这一小块的用量要尽可能的低，这也就是我们为什么要将EasyRTC压缩到500K-800K的原因了！2、另外，WebRTC的调用本就是一个很复杂的过程，很难捋清楚脉络，所以，一套行之有效的RTC调用流程封装就至关重要了。

EasyRTC在hi3516cv610芯片上能双向通话、发送文字以及二进制指令，总体运行效果非常好！

这个对比EasyRTC.h头文件看，要轻松多了~

简单进行了一些尝试之后，有很大可能，我们能够将EasyRTC的SDK空间占用缩小到500K上下，这就给集成商、硬件厂商极大的操作空间，EasyRTC目前已经发布在Github：https://github.com/EasyDarwin/EasyRTC，大家可以体验一下水准！专为此事，我们近期做了一些讨论，通过修改编译参数，例如使用-Os(优化体积)代替-O2或 -O3(速度优先可能导致代码膨胀)、使用启用 -flto允许跨模块优化，消除冗余代码等等方式，缩小SDK的大小！

之前采用RTSP+RTP组播的方式做过一款同屏软件：EasyScreenLive，当时就是在live555的基础上，修改SETUP时RTP UDP的发送地址为局域网组播地址，采用RTP组播的方式可以做到类似于IPC内的RTSP Server那样的低延时效果，延时差不多在100~200ms，当然，这个跟终端的编码和解码的效率有很大关系，编码实际占了很大一部分时间消耗。基于WebRTC的超低延时同屏技术。

最近智能硬件（IPC摄像机、智能门铃、智能猫眼、宠物机器人、陪护机器人、带屏可视音箱、带屏台灯等等）与微信/小程序视频通话的功能火起来了，视乎传统硬件终于开始走出了向WebRTC突破的一步，相信未来WebRTC在C端硬件上，将会独领一档存在。之前我们也描述过，微信或者小程序与智能硬件的通话主要的优势就是利用了微信在手机中的霸主地位，无论是App的安装普及程度，还是实时推送的到达率，都是top级别的，用户只需要做好硬件侧和应用侧的开发，无需过多关注底层推送接口的事情。实际，微信小程序与智能硬件之间的VoI

如何能够让嵌入式智能硬件与用户之间形成可靠的联系？j借助于WeChat在社交领域的霸主地位，再借助IPC产业的发达优势，于是“IPC+WeChat”就是一个完美的组合了，不用再为呼不通而烦恼。

WebRTC的主要优势是支持浏览器内核之间的实时通信，尤其是现在App原生应用越来越少，小程序应用越来越多，WebRTC作为Web浏览器之间进行实时音频、视频和数据传输的能力协议，就特别凸显优势了。

综合以上的原因，要想打造一个能在IPC上可用的WebRTC SDK，技术难度之高，远超目前常规的流媒体开发！

那么，这么多场景的需求，有什么样的方案能解决这些需求呢？我们简单做一些分析：RTSP？答案是否定的，1、RTSP属于一种单向的流传输协议，音视频流只能从设备端传向控制端（或者客户端），当有对讲或者控制数据需要发向设备的时候，需要再开通道；2、RTSP可以做到低延时，但做不到持续的、高QoS的视频低延时；RTMP？答案跟RTSP一样，也是否定的，可能RTMP比RTSP还要差一点，不但协议晦涩，而且纯TCP基础上的RTMP是肯定无法做到持续低延时的，双向对讲就更不可能了；GB28181？

注意：现在很多市面上的软硬件通过转码H.265成H.264的方式来支持WebRTC，个人理解，这既费硬件又是技术的倒退！

众所周知，目前市面上存在的大部分的直播流技术，采用的直播推流都是RTMP协议，主要的架构框架大概为RTMP推流、服务端同步转换并输出RTMP、FLV、HLS等多种协议，相比于10年前的直播技术，这种技术体系已经是非常先进的了，各种低延时的策略都有了，看起直播来也算是比较流畅的：但当我们将这种技术应用到行业中的时候，就会感受到弊端：当推流设备为无线设备或者在网络较差的环境下时，RTMP的推流会出现较大的延时；播放端一般采用的是RTMP或者HTTP-FLV技术，其主要保障的是数据的完整性，而实时性的控

WebRTCWebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。EasyRTC基于WebRTC，凭借多年音视频开发经验并结合实际情况，开发了 基于WebRTC的音视频通讯云平台，提供互动教学、连麦直播、视频会议、指挥调度等多种音视频跨平台解决方案。WebRTC历史2010年5月，Go

5G网速带来的提升，也带来了两个很大的优势，一个是传输速度更快了，另一个就是网络容量更加大了；这将有效提升实时音视频等多媒体应用的发展速度。在5G视频的未来应用领域里面，例如：无人驾驶、远程看护、远程辅导、金融双录、保险理赔等等，对于网络的要求都很高，但仅仅是网络变的更好，变得像内网，并不代表音视频产品的体验就变的更好。5G已经开始商用，网络带宽优势变得更大，也不再成为系统性能的瓶颈，公网变成了内网，但这并不能改变传输效果，试想一下，我们在内网测试系统的时候，效果真的有那么流畅吗？

应急指挥场景下，我们大概要接入哪些视频源：固定监控：接入协议包括GB28181、Onvif、SDK、Ehome、DSS、IMOS等等；无线监控：接入协议包括RTMP、GB28181、私有协议等等；无人机：接入协议包括RTMP、私有协议；视频会议：接入协议包括SIP、H.323、WebRTC等等；以上这些接入协议，如果要统一做输出，在现有流行的场景下，我们可能会选择HTTP-FLV、HLS、RTMP、RTSP等方式输出，但这些协议方式在应急指挥场景下，都没有办法达到非常好的实时效果，所以，我认为

回想到2012年我做EasyDarwin开始，当时应该还没有H5的概念，RTSP/RTP都是属于较为新兴的技术，我当时用live555的DarwinInjector做RTSP推流，用EasyDarwin做流媒体服务器，用live555的RTSPClient做客户端，开始搭建起来了一套完整的流媒体服务器系统。后来到2014年，感觉到DarwinInjector用起来不方便，而且可控性较差（主要还是live555的结构太复杂，改起来费劲），所有就开发了自己的RTSP推流SDK：EasyPusher，和播放SD

WEBRTC“WebRTC，名称源自网页实时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术，Google开源了这项技术！”就冲着6000多万美金的技术，就很值得研究一下！WebRTC提供了视频会议的核心技术，

NOTE：This project is active in Google code: http://code.google.com/p/rfc5766-turn-server/