开源实时音视频技术WebRTC的文章,容联即时通讯云启动4月注册/认证送大礼活动

摘要为了回馈用户,在万物苏醒的四月春风中,容联即时通讯云启动4月注册/认证送大礼活动。注册就有礼!认证更加送大礼!介绍为什么云通讯服务偏爱容联?因为它拥有全通讯产品矩阵,一站式选择,一站式服务,一站式解决方案。容联云通讯,让您的每个应用会说话。为了回馈用户,在万物苏醒的四月春风中,容联云通讯给您送礼啦。注册就有礼!认证更加送大礼!活动时间及范围1、活动时间:2016-04-05
10:00至2016-04-28
15:002、活动对象:新注册用户及未进行企业认证的老用户活动礼品及发送方式(1)认证成功,即送500M流量(认证审核通过的两个工作日内,充值您认证的手机号中))(2)转盘抽奖,100%中奖100条短信、300分钟通话、云通讯产品1折折扣券:中奖后,可在资源余量中查询300M流量:中奖后,直接充值到您填写的手机号孙小圣、加湿器:中奖后,三个工作日内以快递的方式邮寄(3)特价资源包(为三选一,购买后,可在资源余量中查询)温馨提示为了便于您及时收到礼品,请填写正确信息,地址、电话、姓名,如信息,容联云通讯将不会补发礼品。活动地址

摘要作为Google开源的技术,WebRTC并不是一个可以拿来就用并且性能很好的产品,而且正如众多的其它开源技术一样,WebRTC的发展并没有期待中的快。前言随着移动互联网和智能硬件的快速发展,音视频技术从独立应用普及到了嵌入式应用中,不管是智能硬件、手机应用或是Web程序中的许多模块都越来越依赖于音视频技术。2011年Google将WebRTC项目开源,让许多开发者眼前一亮,忍不住的加入了研究WebRTC的队伍中。他们大多数都认为WebRTC是Google公司的开源项目,肯定是拿来就用,而且效果还能很不错,想着开发高大上的音视频功能由此会变得so
easy。但是!WebRTC的开发真的是Google送到嘴边的免费午餐吗?下面来介绍一下WebRTC自身发展的现状,以及目前开发WebRTC的现状。目前的进展WebRTC在被Google开源之前,其价值就已经得到了充分的认可,比如QQ就使用了WebRTC的部分技术。WebRTC的发展情况可以从标准规范和浏览器支持这两个方面看。WebRTC标准是由W3C和IETF所联合制定的,在2016年1月28日,W3C公布了最新的WebRTC标准,标准中定义了WebIDL中一系列的ECMAScript
API来允许使用合适的RTP的浏览器或设备来接收/发送媒体,详细内容可以访问
Chrome浏览器、Firefox浏览器和Opera 20浏览器,但是IE浏览器及Apple
Safari浏览器还未支持WebRTC技术。对于开发者而言,WebRTC仍旧高不可攀登WebRTC的开发现状其实并不像大多数人所想象的那么简单,人们普遍的认为WebRTC的代码是开源的所以花很少的时间就能将其集成到项目中去,并且Google这么大的公司的产品质量一定没问题。但是在项目进行中,大家都会发现,WebRTC并不是一块Google白送到面前的肉。首先,编译WebRTC的源码就是一个比较大的挑战,搭建其复杂的编译环境往往会遇到很多意想不到的问题,导致当初计划用几个星期的时间来搞定项目,却发现这几个星期连编译都没搞定。还有,WebRTC中很多的参数都是由GIPS公司的工程师们依靠经验所设定的值,这就会出现卡顿、延时、回声、丢包、多人视频不稳定等问题,并且由于公网的稳定性或机型适配等外在因素,以上问题在项目上线后会更加严重。总而言之,WebRTC虽然提供了一套音视频实时通讯的解决方案,但是在实际应用中,由于网络传输、设备适配以及多方通话上都存在很多问题,效果并不理想。可见WebRTC的开发并不像大部分人想象的那样容易。在自己开发WebRTC之外,目前在市场上有很多第三方的音视频SDK可供选择,比如声网、腾讯、Intel、天翼RTC、网易云信、环信、融云、anychat等等,虽然这么多厂商提供的服务都大同小异,但他们的技术架构可能完全不同,比如天翼RTC是WebRTC
SDK,腾讯是Native
SDK。给开发者的建议由于WebRTC的复杂性和尚未完善性,下面的这些建议结合自己的实际参考:1、音视频不是公司的核心方向,建议使用第三方SDK。2、项目时间紧,有多人视频场景,使用场景依赖于手机端,建议使用第三方SDK。3、公司没人音视频技术人才,建议使用第三方SDK或者技术外包。4、如果公司实力、财力、人力雄厚,时间也不紧急,可考虑WebRTC集成开发,虽然会有很多坑,但总是能填平的。5、如果音视频技术是公司的核心方向,但不想花太多时间去研究WebRTC,可直接找熟悉WebRTC的人来培训。6、项目时间不紧急、没有多人视频需求且音视频质量要求不高,可考虑WebRTC集成开发。附录:更多实时音视频技术文章[1]
开源实时音视频技术WebRTC的文章:《开源实时音视频技术WebRTC的现状》《简述开源实时音视频技术WebRTC的优缺点》《访谈WebRTC标准之父:WebRTC的过去、现在和未来》《良心分享:WebRTC
零基础开发者教程(中文)[附件下载]》《WebRTC实时音视频技术的整体架构介绍》《新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?》《WebRTC实时音视频技术基础:基本架构和协议栈》《浅谈开发实时视频直播平台的技术要点》《[观点]
WebRTC应该选择H.264视频编码的四大理由》《基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?》《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》《简述实时音视频聊天中端到端加密(E2EE)的工作原理》《实时通信RTC技术栈之:视频编解码》《开源实时音视频技术WebRTC在Windows下的简明编译教程》《网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?》>>更多同类文章
……[2]
实时音视频开发的其它精华资料:《专访微信视频技术负责人:微信实时视频聊天技术的演进》《即时通讯音视频开发(一):视频编解码之理论概述》《即时通讯音视频开发(二):视频编解码之数字视频介绍》《即时通讯音视频开发(三):视频编解码之编码基础》《即时通讯音视频开发(四):视频编解码之预测技术介绍》《即时通讯音视频开发(五):认识主流视频编码技术H.264》《即时通讯音视频开发(六):如何开始音频编解码技术的学习》《即时通讯音视频开发(七):音频基础及编码原理入门》《即时通讯音视频开发(八):常见的实时语音通讯编码标准》《即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述》《即时通讯音视频开发(十):实时语音通讯的回音消除技术详解》《即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解》《即时通讯音视频开发(十二):多人实时音视频聊天架构探讨》《即时通讯音视频开发(十三):实时视频编码H.264的特点与优势》《即时通讯音视频开发(十四):实时音视频数据传输协议介绍》《即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况》《即时通讯音视频开发(十六):移动端实时音视频开发的几个建议》《即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生》《实时语音聊天中的音频处理与编码压缩技术简述》《网易视频云技术分享:音频处理与压缩技术快速入门》《学习RFC3550:RTP/RTCP实时传输协议基础知识》《基于RTMP数据传输协议的实时流媒体技术研究(论文全文)》《声网架构师谈实时音视频云的实现难点(视频采访)》《浅谈开发实时视频直播平台的技术要点》《还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!》《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》《移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡》《如何用最简单的方法测试你的实时音视频方案》《技术揭秘:支持百万级粉丝互动的Facebook实时视频直播》《简述实时音视频聊天中端到端加密(E2EE)的工作原理》《移动端实时音视频直播技术详解(一):开篇》《移动端实时音视频直播技术详解(二):采集》《移动端实时音视频直播技术详解(三):处理》《移动端实时音视频直播技术详解(四):编码和封装》《移动端实时音视频直播技术详解(五):推流和传输》《移动端实时音视频直播技术详解(六):延迟优化》《理论联系实际:实现一个简单地基于HTML5的实时视频直播》《IM实时音视频聊天时的回声消除技术详解》《浅谈实时音视频直播中直接影响用户体验的几项关键技术指标》

摘要针对近期的服务稳定性问题,即时通讯云服务端LeanCloud进行相关优化,并在接下来的服务过程中启用改进和即时通讯云计费方式。以下为来自即时通讯云
LeanCloud官方的消息:LeanCloud
近期经历了比以往更频繁的稳定性方面的事故,其中有的是因为容量规划上的不足导致服务收到异常流量影响,有的是对上游服务商的域名攻击,有的是针对
LeanCloud 的 DDoS 攻击。LeanCloud
一直将服务的稳定性视为生命线,每次事故之后,都会严肃地总结并明确改进方案。我们也会把事故报告发布到博客上,确保用户们知晓事故原因和过程,以及后续我们要执行的改进措施。为让用户了解我们为此所做出的努力,我们想向大家通报一下在改进措施方面的进展。已经完成的改进措施有:为应对将来可能出现的上游服务商域名被攻击的情况,实现更灵活的域名动态切换,以便在必要时及时切换至其他域名,保证云服务对外服务的可用。完善应对
DDoS
攻击的策略和措施,把受攻击后恢复服务的时间缩短到分钟级。事故公告流程增加了短信通知渠道,确保开发者及时收到信息。(我们在最近的
DDoS
攻击的几十分钟内一共给所有用户发送了三次短信及时更新进展)。正在进行的措施有:增加新的监控措施,对前端网络入包量进行监控,防止网络转发量超过
VM 能力限制。调整前端 VM
配置,使用高包量机型,增大处理能力。改进前端服务器扩容方式,使用 docker
镜像来加快新节点部署上线的进度。API
服务对外增加多路备选域名,降低针对域名的攻击造成的影响。除了技术上的改进外,我们也对计费方式中的不合理之处进行了重新思考。过去我们的存储和即时通讯实时消息服务都是按照一个月的总使用量来计费的,这样造成了一些问题。比如如果一个应用在一个月里发生了
10 亿次 API
调用,我们并不区分这些调用是平均分布在整个月,还是集中在少数几天。而这两种情况对容量规划的要求是非常不同的,如果不做区分,就容易造成资源上的分配不及时,给运维工作造成风险和压力。另外由于存储和即时通讯实时消息是按月后付费,LeanEngine、LeanCache、短信是实时扣费,不同的计费周期和方式给很多用户造成了财务流程上的困扰。所以我们将把所有服务调整为一致的实时扣费的模式,并且存储和即时通讯实时消息服务将调整为按每天用户设定的容量上限收费,其中数据存储的计费依据将是并发请求数的上限,即时通讯实时消息服务的计费依据将是当日使用服务的用户数上限。这样用户可以自己调整预留的资源,确保满足需求。由于计费周期缩短到天,也能满足只在特定日期有超高流量的应用兼顾较低的预算和充足的资源。具体的方案和数字我们还在制定,会在第一时间与用户沟通。同时我们也会确保老用户有平滑的过渡体验。LeanCloud官方地址:

相关文章