rtc

前言 上一篇讲解了怎么实现Android uni-app封装原生插件，这篇讲解一下，把anyRTC的RTC（音视频通讯）封装uni-app 实现音视频通话。 不了解anyRTC的小伙伴，可以点击下面链接： 开发者官网 1.效果图 先上图，后讲解！ 1.1 首页 1.2 游客界面 1.3 主播界面 2.GitHub地址 uni-app demo: 点击下载 3.demo下载： 下载地址： 点击下载 扫码下载： 4.代码 4.1 集成插件 const RtcModule = uni . requireNativePlugin ( 'AR-RtcModule' ) ; AR-RtcModule：插件名称，首页集成插件 4.2 初始事件回调 //callback 接收 callbackFn ( ) { RtcModule . setCallBack ( ( res ) = > { switch ( res . engineEvent ) { case "onWarning" : this . promptFn ( "warn" , res . warningCode ) ; break ; case "onError" : res . errorCode != 18 ? this . promptFn ( "error" , res . errorCode ) : '' ; break ;

一、需求背景 5G网速带来的提升，也带来了两个很大的优势，一个是传输速度更快了，另一个就是网络容量更加大了；这将有效提升实时音视频等多媒体应用的发展速度。在5G视频的未来应用领域里面，例如：无人驾驶、远程看护、远程辅导、金融双录、保险理赔等等，对于网络的要求都很高，但仅仅是网络变的更好，变得像内网，并不代表音视频产品的体验就变的更好。 5G已经开始商用，网络带宽优势变得更大，也不再成为系统性能的瓶颈，公网变成了内网，但这并不能改变传输效果，试想一下，我们在内网测试系统的时候，效果真的有那么流畅吗？ 二、RTC的实际应用 我们有时候在研发测试系统的时候，协议的选择也是非常关键的一环，每一种协议的侧重点不一样，比如RTP侧重RealTime，HTTP侧重Web友好，HLS侧重SmoothStreaming，所以，不同的行业应用要选择对应的视频传输协议； WebRTC已经发展了很多年，从早期的网页视频会议，现在几乎可以理解：WebRTC=Web + RTC，RTC也就是即时通信，WebRTC超越Web，可以应用于非常多的应急指挥的场景： 消防领域 消防无人机实时视频具有机动快速、使用成本低、维护操作简单等技术特点，具有对地快速实时巡察监测能力，是一种新型的中低空实时视频成像和红外成像快速获取系统。消防无人机通过摄像头将远程的火灾视频发回到指挥中心，让消防战士了解真实的火灾状况

关于uFun学习板——"满满的爱和正能量" uFun 是由 @张进东 张工组织发起的一个开源的学习板，设计初衷是为了帮助学生更好的理解电子知识和开发技巧，同时又能对学生毕业找工作有很明显的帮助。张工于2014年10月提出这个想法，并发到了博客上，不久就得到了全国各地几十位小伙伴的支持和响应，大家天南海北，筹钱献力，多位在职工程师，利用业余时间共同设计了这块学习板，经过几次的设计验证，还有一些厂商的支持，400套学习板诞生了。 关于uFun的LOGO含义 ：“U”上面两个点是伸出的双手，象征着热情的拥抱，是工程师与学生之间爱的传递；“F”是family；“un”是取形电路走线，连接美好。这块板子里凝聚的满满都是爱和正能量！相信每一个参与者背后都有一段奇妙的故事。 最近有幸能得到uFun开发板的试用机会，我是3月4号提交的申请，3月8号收到的板子，可以说面包板社区的效率还是很高的，在这里感谢面包板社区、 @张进东 张工及所有为了这个项目奉献的人！正好今天是周末，有时间写一下开箱报告，希望我的这篇文章，能对那些刚拿到板子的朋友有一些帮助，另外有哪里不对的，也请大家指出，同时也希望能和各位大佬多多交流。 uFun开箱靓照——精致与内涵并存 快递是用的顺丰，到付18元。包装简洁，用泡沫包装的很严实，使用的静电袋包装，可以有效防止运输过程中静电对芯片造成的损坏。板子刚上手

RT-Thread 4.0版本代码Release啦！ 因为支持SMP（对称多核处理器）的缘故，RT-Thread v4.0的发布有些延期。 再包括增加对64位处理器的支持，内核的改动也比较大，应该说是自RT-Thread创建以来内核调整最大的一次。但这份改动可以让对称多核处理器运行RT-Thread时，只需要运行一份实例。当有核空闲时，则会把就绪态的任务分配到这些空闲的核上执行起来，真正做到多任务并发执行，提升整体的计算性能。 本次发布主要有以下调整： 内核： 加入SMP支持和64位处理器支持； 组件： 增加单元测试框架utest、轻型进程实现`components\lwp，并优化部分组件使用体验； BSP： 更新以STM32为基础的新BSP框架，使得BSP达到了对18个STM32开发板的支持；增加多个BSP：LPC54114-lite、Nuvoton-M487、嘉楠K210 、RV32M1 VEGA开发板、华芯微特SWM320、TI TMS320F28379D BSP、Synopsys DesignWare ARC EM Starter Kit等； 工具： RT-Thread ENV工具也发布了v1.1.0正式版； 开发者致谢 在此特别感谢: HubretXie、gbcwbz、fullhan、thomasonegd、NoeXu、liruncong、Bluebear233

ARM嵌入式工控主板是工控领域新推出的一款工控主板，在ARM嵌入式工控主板硬件的性能和功能上都有很大的改进。那么ARM嵌入式工控主板的硬件有哪些用途呢?联智通达小编为您介绍： 　　第一，ARM芯片：ARM处理器是一种16/32位的高性能、低成本、低功耗的嵌入式RISC微处理器。ARM9系列微处理器具有以下特点：5级整数流水线，指令执行效率更高;支持32位ARM指令集和16位THUMB指令集;支持32位AMBA总线接口;全性能的MMU，支持Windows CE、Linux等主流的嵌入式操作系统;支持数据Cache和指令Cache，具有更高的数据和指令处理指令。 第二，ARM PC/104主板：基于ATMEL工业级处理器，标准PC/104工控主板规格，采用8层PCB板高精度工艺，使其具有最佳的电气性能和抗干扰性能，主板可集成了常见的嵌入式系统外围接口，如：PC/104、10/100Mbps网络、串口、TFT-LCD、USB Host/Device、音频、8x8键盘、AD、PMW、计数器、IDE、SD卡、CAN总线、RTC、看门狗等，ARM嵌入式PC/104主板无论从功能、稳定性、功耗、体积、成本上来衡量，都具有很大的优势，在嵌入式系统应用中具有出色的表现。 　　第三，ARM 3.5英寸嵌入式工控主板：基于Cirrus Logic EP9315 ARM9处理器，标准3.5英寸工控主板规格

为了探讨用一套客观，完备的评价系统对在线教育的音视频通信质量做出评价，力求做到定量，准确，横向可对比，并基于线上运行的大数据系统，发掘端到端通信平台存在的问题，找到优化方向，提升在线教育的用户体验，VIPKID音视频团队负责人张武峰在LiveVideoStackCon2019北京站上做了有关在线教育音视频质量评价与感知系统的分享。 文 / 张武峰 整理 / LiveVideoStack 大家好我是来自VIPKID的张武峰，今天我与大家分享的是在线教育音视频质量评价与感知系统。 我有二十余年的音视频开发经验，最早从事传统视频会议方向的探索，后来转向至3G、4G网络下的视频电话。传统视频会议多由专网传输，目标是如何尽可能地实现出色的音画质量；而消费级互联网基于公共网络的环境与专网有很大的不同，遇到的挑战相对于专网来说完全不一样，这就使得我在进入消费级互联网行业时发现，自己之前在开发基于专网的商业级音视频业务当中积累的知识与经验无法有效应对新的业务场景和开发痛点，知识体系的更新重组对我而言是非常有必要的。 2017年我加入了VIPKID，带领音视频团队探索如何更好地将实时RTC技术用于在线教育领域。我之前一直从事技术方面的优化与创新，而这次选题我特意选取了QoE方向，就是因为探索了这么多年的技术，我发现技术最重要的是为实际应用场景带来具有建设性的优化改进

前言：做音视频的小伙伴们多少都遇到过奇怪的BUG（如：卡顿、花屏、绿屏、变声等），表象上矛盾点颇多，推理得出的结论都是：“不应该啊！”，最终你抽丝剥茧，发现真相只有一个：“事出反常必有妖”！ 作者：安果，阿里云高级技术专家，从事阿里云 RTC 服务器研发 奇怪现象 背景：RTC 互动中增加对 RTMP 的支持，实现 RTC 与 RTMP 相互订阅。 遇到一个奇怪的 BUG，遮挡住 RTC 端的摄像头，有的 RTMP 播放端（iPad air 2，iPad mini 2/4）会偶发绿屏。 要不先发版？ 初步分析问题后，我们认为这是：一个偶发的终端兼容性问题，有很大概率需要修改 RTC 端的编码来适配，耗时不好评估。 “距离发版本的时间不到 2 周，要不就先发版本吧？” 这个请求被产品无情的拒绝了（这次真的感谢你们的坚持），测试也反馈了新的情况：iPhone 6 也出现了绿屏，关闭 RTC 端的摄像头也可能绿屏，Mac 摄像头对着白色墙面也可能绿屏（测试的同学们也太能折腾了），同时确认了 RTMP 编码 RTMP 播放时相同场景不绿屏。 编码还是封装的坑？ 疑难杂症先会诊，同编解码的同学一起讨论完后确认两个可能的点： 1.编码的 264 码流不兼容。 2.封装发送的 RTMP 数据不兼容。 我们制定了后续的排查方案： 1.录制 RTMP 编码和 RTC 编码的码流做对比。 2.使用

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

前言 经过了双11和双12的“血拼”，相信大家的购物车基本上已经都空了吧，家里面的快递应该堆也积如山了吧。如今，实时音视频互动已经成为了我们生活中常态。特别是由于疫情的原因，使得数以万计的用户涌入到了线上，为线上应用带来了巨大的流量，无论是在线教育，线上会议，娱乐直播，游戏开黑，都让人们对实时音视频有了全新的认识。 社交娱乐行业发展特点分析 目前，中国网民在移动社交上花费的时间已经超过总盘子的36%，基于深度社交、泛社交、陌生人社交等多元社交类型延伸出来的价值，也在不断放大。 简单举几个例子：游戏领域，因为社交的介入，现象级的手游《王者荣耀》目前注册用户数已经达到了2.4亿，短视频领域，《抖音》目前注册的用户数量突破了8.2亿，当然还有移动电商平台，淘宝，京东，拼多多（相信大家都收到过帮忙砍价的链接吧）等。 互联网社交产品用户需求、用户场景情况分析 1、男女比例符合我国互联网网民分布，核心受众以年轻人为主 智研咨询发布的《2019-2025年中国互联网+社交行业市场供需预测及发展前景预测报告》数据显示：2019年10月中国互联网社交产品独立设备数男性占比为52.8%，女性占比为47.2%，在性别分布上较为均衡，与我国互联网网民性别分布高度一致。从互联网社交产品用户的年龄结构来看，24岁以下的用户占比最高，达到29.7%，30岁以下的用户占比总计56.1%

对于许多与系统相关的任务和进程，使用正确的时区是必不可少的。例如，cron守护进程使用系统的时区执行cron作业，日志文件中的时间戳基于同一系统的时区。 环境 Centos 8 检查现在的时区 timedatectl 是一个 命令 行实用程序，允许您查看和更改系统的时间和日期。 [root@localhost ~]# timedatectl Local time: Tue 2020-03-31 16:35:23 CST Universal time: Tue 2020-03-31 08:35:23 UTC RTC time: Tue 2020-03-31 08:35:23 Time zone: Asia/Shanghai (CST, +0800) System clock synchronized: yes NTP service: active RTC in local TZ: no 更改时区 在更改时区之前，您需要找出要使用的时区名称。要列出所有可用时区，请使用下面的 命令 ： [root@localhost ~]# timedatectl list-timezones … Asia/Samarkand Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Srednekolymsk … 然后使用 set-timezone 选项更改时区