如何做好 Android 端音视频测试?

  在用户眼中,优秀的音视频产品应该具有清晰、低延时、流畅、秒开、抗丢包、高音效等特征。为了满足用户以上要求,网易云信的工程师通过自建源站,在SDK端为了适应网络优化进行QoS优化,对视频编码器进行优化,同时对音频算法进行优化。 推荐阅读 《短视频技术详解:Android端的短视频开发技术》 《如何快速实现移动端短视频功能?》   弱网环境测试   网易云信直播项目上线后,出现了音视频卡顿的问题,音视频卡顿现象通常出现在网络条件不是特别理想的情况,一般直播画面频繁出现缓冲标志或者直播画面一卡一卡的现象。 造成直播视频卡顿的原因: 1、CDN 节点覆盖不全:CDN服务器覆盖不足导致区域卡顿、运营商覆盖力度不足导致区域性卡顿; 2、CDN 接流节点不佳:主播上行推流卡顿导致直播卡顿; 3、主播网络差:数据上传受阻; 4、观众网络差: 数据下行受阻;   分析解决策略: 1、CDN节点覆盖不全:接入多家CDN节点,尽可能覆盖全球网络; 2、CDN接流节点不佳:自建源站; 3、主播网络差:SDK开发对QoS上行调整; 4、观众网络差:SDK开发对QoS下行调整;   测试需求:直播端QoS测试;   测试难点: 1、如何实现低成本、高效率的弱网环境? 2、怎样的网络才是导致用户卡顿的弱网环境? 3、弱网优化参数这么多,如何高效提取分析数据? 4、测试完了,怎么可以快速提供简洁清晰的结果给开发?   弱网测试工具: 弱网损伤仪、network emulator、fiddler、tc; 弱网损伤仪成本比较高,使用复杂;network emulator是微软的开源工具,可以实现带宽、丢包、延时、抖动等弱网参数的限制,被称为简易版本的弱网损伤仪,实现成本比较低,最终搭建弱网环境选择的是networkemulator工具; network emulator工具使用建议: 1、办公环境内使用人多时,4G信号通道出现拥塞,虽然网络上行下行带宽足够,但网络丢包严重,造成限制网络不稳定的现象; 解决方法:开通支持开启5G信道的无线热点,部分缓解网络拥塞的现象; 2、弱网限制效果验证; 弱网环境参数选择; 常见弱网限制参数; 带宽、丢包、延时、抖动、综合网络; 具体数值选择方法: 第一步:逼近法,对上述限制参数从由高到低、由低到高给出范围; 第二步:业界标准和产品需求去反向要求开发优化的力度; 第三步:通过大数据筛选用户卡顿场景数据,覆盖用户出现卡顿的场景; 弱网测试常用参数: 测试常用高清视频分辨率为640*480,一般要求码率为800kbps以上,带宽限制一般设置为三挡,800kbps、600 kbps以及400kbps;丢包会设置5%、3%、1%;延时会设置300ms、200ms、100ms等限制;综合网络情况是将带宽、丢包以及延时进行结合的参数;为了监控用户实际使用的一些情况,也会进行一些4G、3G网络的覆盖; 测试流程: 开发提交测试之后,测试会针对入网效果进行简单测试,针对网络场景发现的bug返回给开发继续优化,开发优化完成之后传给测试,测试将结果再传给开发进行详细优化,过程需要反复进行,下图为测试开始进行的环境图:   直播与播放连接在同一个Wifi下面,用network emulator进行弱网限制,直播与播放都是从CDN拉流,然后获取直播和播放端一些音视频相关的统计数据,在播放端通过观测方式主观评测优化效果。 测试效率分析: 1、Android 端数据手工收集; 2、数据导入excel分析,耗时间; 3、测试工作量比较大; 解决策略: 1、Android 端开发 MCN 性能数据收集以及日志分析工具; 2、测试工具平台接收来自Android端的数据,进行数据汇总分析; MCN Android 端:提供设备性能数据上传,包括CPU占用率、内存占用率、电量等数据,SDK统计数据上传,辅助弱网测试、视频测试等的开展。 实现原理:利用Android的系统API获取系统性能参数getProcessMemoryInfo,读取SDK存储在本地的日志,通过HTTP接口上传到测试工具平台展示。 测试工具平台:支持解析日志文件和HTTP请求,利用highcharts作图,提供数据对比分析作图并且保存功能,大大降低了测试完成之后数据整理作图分析的工作量,给开发提供了最为直观的测试结果。 测试执行: 测试结果展示:   上图中的蓝色线是实际带宽,黑色线代表的是评估带宽,从aos-1108-1这个图可以看出评估以及实际占用的带宽是非常接近的,通过这个图开发可以了解优化的效果,测试可以了解测试的结果。   视频测试   用户在视频实际使用过程中会发现,网络以及设备一致时,有些主播视频可以更加清晰;有些主播动态的图片会模糊,出现马赛克的情况;有些主播画面看起来比较细腻,甚至主播的毛孔都可以清晰看到,而有些主播看起来画面是模糊的;这就需要开发通过替换编码器的一些算法或者做一些参数的调优对编码器进行优化; 安卓端视频测试方面会影响的因素包括:拍摄场景、编码参数、设备性能、安卓兼容性以及网络。   前期的视频测试主要依靠主观评估,通过人肉眼查看编码的不同序列,运动剧烈的画面看马赛克、复杂的画面需看细节、录屏密集文字看边缘锐度等等;客观评估需要用PSNR。 PSNR评估是对编码器性能的评估,在排除网络影响的情况下,依赖一些视频序列评估编码器的编码质量。 同时视频测试还需要看一下码率控制,看一下输出码率是否符合设置给编码器的码率; 视频测试还需要考虑移动端设备的性能,相同编码参数下的CPU、内存的占比情况;   测试执行:   测试环境会用到MCN Android端去搜集实时音A端和实时音B端的数据,需要用network emulator模拟一些网络参数的影响,然后去测试工具平台上进行评估。   音频优化测试   音频决定了70%的用户体验,虽说用户对画面的直观感受是以看为主,以听为辅。如果说一个主播在直播时只有画面没有声音,这将直接影响用户体验;如果主播直播时声音断断续续,或者主播声音质量较低,都会影响直播的质量。 在音频方面面临的挑战有:音频编码器,不同的音频编码器有Opus,AAC等,这些编码器里面的部分算法不太一样,其中包括对音频的处理,对声音峰值的处理,对网络参数的应对,它的处理方式不太一样。实时音端的编码器用的是Opus,Opus相对于AAC来说,编码码率会更低,能够提供一些更高质量的音频体验;网络对音频体验也有影响,无论音频还是视频都会受网络的影响;回声消除对音频体验也有影响,如果没有回声消除,用户的音频体验会相对较差;啸叫以及安卓设备的差异都会对音频质量产生影响。   音频质量的评估 音频从IP电话开始发展,音频的技术处理已经相对成熟,同时对音频的测试技术也相对成熟,目前有较多付费软件可以实现对音频质量的评估,包括VQT等; VQT:语音质量客观评估工具,可以包括 POLQA(ITU-T P.863),PESQ(ITU-TP.862),PESQLQ / LQO(P.862.1),PESQ WB(P.862.2),PAMS(ITU-TP.800)和PSQM / PSQM +(ITU-TP.861)等音频质量的评估; 目前网易云信使用VQT中的POLQA来评估网络变化对音频的影响,该评估主要使用了MOS分值,这是衡量通信系统语音质量的重要指标,5分为评估的最高分; 安卓端的覆盖策略首先会提供一个线上数据收集平台,根据不同的手机型号提交测试需求,也会挑选市面上TOP20的机型去做覆盖,也会挑选一些用户反映问题最多的机型去做一些针对性测试覆盖; VQT中POLQA的环境配置:   优化后的POLQA环境配置:   优化后的POLQA环境配置可以对网络参数进行评估,对数据进行整合,实现多组数据的对比,实现自动化结果的展示。   以上就是安卓端音视频测试全过程,想要获取更多产品干货、技术干货,记得关注网易云信博客。      

2018-11-20

网易云信独家技术支持,壹点灵领跑心理服务行业

随着经济的快速发展和社会竞争的不断加剧,人们的生活节奏逐渐加快,压力也随之增长,越来越多的人步入心理亚健康的状态。国家统计局曾公布一组数据,中国每年因自杀身亡的人高达28.7万,而因失学、下岗、婚姻问题等引起的各种心理问题,其人数则是精神疾病和自杀人数总和的10倍以上。瞄准了亚心理健康的庞大人群需求,越来越多的社会资本进入心理健康市场,心理健康领域近两年突然成为风投重点关注话题。 作为互联网心理服务行业的“独角兽”,壹点灵在不久前完成了数千万的A+轮融资,全面领跑心理服务行业。目前,壹点灵平台提供婚恋情感、情绪压力、亲子关系、职场人际、心理测试、心理资讯、心理课程等一站式心理服务,拥有300余万注册用户,10000多名专业心理咨询师,2亿多分钟的付费服务时长以及120万小时的公益服务时长,在成立的三年中,壹点灵已经帮助15万个出现矛盾的问题家庭进行修复和重建。 网易云信独家技术支持,保护用户隐私同时高效沟通 众所周知,对于心理咨询行业,沟通是刚需。通过接入网易云信的即时通讯技术和音视频技术,用户与心理专家可通过语音、文字、图片等形式进行交流。双方在咨询前进行简单的沟通可以帮助咨询师快速判断患者的情况,从而大大提高咨询体验,提高咨询效率。 除了沟通问题,隐私问题也是互联网时代用户最为关注的问题之一。作为咨询方,在倾诉心理问题的时候,他们大多都不愿意透露自己的真实信息;而作为咨询师,提供心理辅导只是自己的工作,生活中的真实信息也不希望被暴露而引起其他麻烦。网易云信的专线电话在满足专家和用户实时电话咨询的同时,使用自定义显号,隐藏双方信息,有效的保护了双方隐私。 成立三年来,壹点灵不仅仅提供心理咨询服务,更是努力为有志于实现心理学价值的心理学专业人士提供最全面的学习平台,通过案例教学、职业督导、大咖教学、咨询师赋能系统等多种方式赋能咨询师。网易云信的直播、点播技术满足了壹点灵往心理教育方向的拓展需求。 壹点灵作为一个在线服务平台,肩负着“让天下人更快乐”的使命和责任。他们一方面为用户对接合适的心理咨询师,帮助用户解决心理问题;另一方面帮助咨询师获取更多用户,拓展专业知识,提高从业水平。在壹点灵丰富的业务场景中,网易云信全面提供技术支持,满足了各个场景下的技术要求,成功助力壹点灵全面领跑心理服务行业。未来,网易云信将会持续提供稳定技术,与壹点灵一起,不畏风雨,砥砺前行。    

2018-11-20

音视频技术“塔尖”之争,网易云信如何C位出道?

  音视频技术“塔尖”之争,网易云信如何C位出道?   社交+美颜、抖音短视频、在线狼人杀、直播竞答、子弹短信……,过往两三年间,互联网新产品和新玩法层出不穷,风口不断切换。这些爆红的网络应用背后,都有一些共同的特征,例如音视频与社交功能的融合。 近期,网易旗下的通讯与视频云品牌网易云信公布了成立三年来的“成绩单”:累计服务60万开发者和年均200%以上的增长速度,音视频业务线更是增势强劲。对此,网易云信CTO赵加雨表示,除了市场的窗口期,平台自身在音视频技术领域的持续攻坚等内生动力才共同成了这份“高分答卷”。   应用风口来袭,音视频功能渐成标配 根据行业研究机构艾瑞发布的《2018年中国视频云服务行业研究报告》,2017年,国内视频内容行业整体市场规模达到1215.2亿元。其中,泛娱乐直播、短视频等细分领域的爆发催生了大量的视频流量需求。 图:艾瑞视频云服务报告显示音视频市场规模持续增长 除了传统的视频内容应用,音视频所出现的场景远不止于此,它可以嵌入在线教育、远程医疗、智能硬件、企业服务软件等更广泛的垂直领域内,为上述产品提供音视频的功能,因而也逐渐成为互联网产品的刚需和标配。   音视频技术的“塔尖”之争,少数玩家掌握的技术门槛 行业风向、用户口味、产品玩法、技术迭代,种种这些都在快速变化。在“唯快不破”的世界,跟上节奏甚至成为领跑者,才有更大的成功可能。另一方面,音视频技术的研发却非一日之功,甚至有些“慢工出细活”的味道。赵加雨将音视频技术的研发形容为金字塔尖的技术比拼,一是 音视频开发涉及多个技术栈,对开发人员的技术能力要求很高。二是二次开发难度大,涉及更专业的技术细节优化。三是客户希望获得可满足实际应用场景的整体解决方案,需要技术团队更深的理解C端产品。   “尽管开发者可以使用一些开源项目搭建出产品Demo,或形成一个简单应用,但要达到稳定可靠的性能要求,并且在任何场景下都能做到流畅不卡顿,仍然是很大的挑战性。这也是音视频技术的专业服务集中于少数大厂的主要原因。”赵加雨总结道。   网易云信的三年攻坚,助推音视频技术实现工业级应用 作为技术立身的品牌,网易云信的技术攻坚重点围绕上述难点进行,其自研的工业级音视频技术框架NRTC,以全面、灵活、易用的工程化解决方案已获得市场的验证,证明其可帮助用户实现了便捷、快速开发和部署,进而有效降低了音视频技术的使用门槛。 图:网易云信自研的工业级音视频技术框架NRTC架构示意图   此外,赵加雨介绍,基于这套成熟框架,技术团队进行了诸多技术细节的优化,从而形成了鲜明的技术优势。譬如,在架构的优化上,基于Web端搭建的点对点的音视频通话Demo在实际应用时的连通率通常较低,使用场景也受限。要确保连通率,并且还能扩展到多人群聊的场景中使用,就需要进行一系列的技术优化。网易云信基于NRTC框架对Web端进行的优化,支撑起一对一以及多人在线场景下的流畅通话体验。在用户端,弱网和带宽竞争等问题会引起卡顿等现象,破坏用户体验。云信的技术团队通过带宽优化,能够准确理解和预判当前的网络环境,进而采取对应的抗丢包策略。网络基建方面,网易云信构建起一张覆盖全球的骨干网,在其中设置了很多专线,并且有自建的数据中心,确保全球客户获得流畅的音视频交互体验。   细节决定品质,精益求精方显匠心精神   尽管PaaS云服务厂商通常隐身于幕后,但“闭门造车”显然行不通,必须充分考虑到C端产品的趋势和用户体验。赵加雨介绍,网易云信提供底层技术的同时,深入垂直领域和具体应用场景中,交付给更为完整的解决方案。以年初刮起的直播竞答之风为例,对于产品开发者来说,抓住时间窗口尤为重要。网易云信团队凭借以往服务娱乐社交类应用的经验,迅速推出直播竞答解决方案。如果说社交娱乐的案例体现了速度感,那么,在线教育场景则代表了技术硬实力。在VIP陪练的案例中,网易云信通过算法优化处理丟音、失真、回声消除等常见问题,满足在线音乐教学对音质的严苛要求。对于在线医疗、智能硬件等应用,需要对诸多技术细节进行研发。譬如,满足穿戴设备对低功耗的要求。远程医疗平台在确保音视频通话质量之余,实现多终端访问、直播回看、文档共享以及隐私保护等功能。   对于未来音视频技术的发展方向,赵加雨表示,目前行业内能够同时将IM与音视频技术做好的机构凤毛麟角。网易云信用三年时间交出了一份高分答卷,得益于多年专注而成的技术积累。同时,秉承匠心精神,甚至完美主义的倾向让团队对细节的追求更加精益求精。   最后,赵加雨强调,互联网的创新步伐不会减速,比如,5G和物联网的应用正在加速落地,音视频编解码技术也在快速迭代。网易云信输出的是技术能力,只有确保自身的与时俱进,才能赋予客户更好的东西。   ###    

2018-11-20

5分钟学会Java9-Java11的七大新特性

现在Java有多元化的发展趋势,既有JS又有C++还有C#的影子,不学习那是不行滴。 来来来,花5分钟看看Java9-Java11的七大新特性,还有代码样例。 Java11 发布了,然而很多公司还在用Java 8 ,这里简单介绍一下 Java 9 -11 引入的新语法和API。 本地变量类型推断 Java 10 就已经引入了新关键词var,该关键词可以在声明局部变量的时候替换类型信息。本地(local)是指方法内的变量声明。 Java 10之前,你需要这样声明一个String对象。 在Java10里头可以使用var替代String,表达式变成这样: 用var声明的变量仍然是静态类型的。 不兼容的类型无法重新分配给此类变量。 此代码段无法编译: 当编译器无法推断出正确的变量类型时,也不允许使用var。 以下所有代码示例都会导致编译器错误: 局部变量类型推断可以泛型。 在下一个示例中,Map <String,List <Integer >>类型,可以将其简化为单个var关键字,从而避免大量样板代码: 从Java 11开始,lambda参数也允许使用var关键字: HTTP Client Java 9开始引入HttpClient API来处理HTTP请求。 从Java 11开始,这个API正式进入标准库包(http://java.net)。 让我们来探索一下我们可以用这个API做些什么。 新的HttpClient可以同步或异步使用。 同步请求会阻止当前线程。 BodyHandlers定义响应体的预期类型(例如,字符串,字节数组或文件): 也可以使用异步来执行相同的请求。 调用sendAsync不会阻止当前线程,而是返回CompletableFuture来进行异步操作。 我们可以省略.GET(),因为它是默认的请求方法。 下一个示例通过POST将数据发送到给定的URL。 与BodyHandler类似,您使用BodyPublishers定义作为请求主体发送的数据类型,如字符串,字节数组,文件或输入流: 最后一个例子演示了如何通过BASIC-AUTH执行授权: Collections List,Set和Map等集合已经用新方法扩展。 List.of从给定的参数创建了一个新的不可变列表。 List.copyOf创建列表的不可变副本。 因为list已经是不可变的,所以实际上不需要实际创建list实例的副本,因此list和副本是相同的实例。 但是,如果你复制一个可变list,那么复制确实会生成一个新实例,因此保证在改变原始list时没有副作用: 创建不可变map时,您不必自己创建map条目,而是将键和值作为参数传递: Java 11中的不可变集合仍然使用Collection API中的老接口。 但是,如果尝试修改不可变集合,则会抛出java.lang.UnsupportedOperationException。 可喜的是,如果尝试改变不可变集合,Intellij IDEA会通过发出警告 Streams Streams是在Java 8中引入的,Java 9增加了三个新方法。 单个参数构造方法: 增加 takeWhile 和 dropWhile 方法,用于从stream中释放元素: 如果对Stream不熟,可以参考这篇文章[1]。 Optionals Optionals提供了一些非常方便的功能,例如 您现在可以简单地将Optional转换为Stream,或者为空Optinal提供另一个Optional作为备胎: Strings Java11 给String增加了一些辅助方法来修剪或检查空格等功能: InputStreams InputStream增加了transferTo方法,可以用来将数据直接传输到 OutputStream: 其他的一些VM特性 从Java 8 到 Java 11引入了很多新特性,以下是这些特性的列表: Flow API for reactive programming Java Module System Application Class Data Sharing Dynamic Class-File Constants Java REPL (JShell) Flight Recorder Unicode 10 G1: Full Parallel Garbage Collector ZGC: Scalable Low-Latency Garbage Collector Epsilon: No-Op Garbage Collector Deprecate the Nashorn JavaScript Engine 译者注:对于译者来说还是Application Class-Data Sharing(CDS),ZGC和Flight Recorder比较有吸引力一点。关于ZGC,可以参考前段时间高可用架构关于ZGC的文章。

2018-11-19

三年深入探索,网易云信让在线医疗做到技术“在线”

在线医疗的模式已相伴人们走过多年。近期,国家卫健委和国家中医药管理局颁布的《远程医疗服务管理规范(试行)》等一系列政策使在线医疗再次受到关注。同时 ,作为共同探索“互联网+医疗”的技术品牌代表,网易云信在过往三年间,以自身扎实的IM和音视频技术为在线医疗的创新赋能,也在亲历着技术带给这一行业的变化。   几经沉浮  在线医疗一直处在特别的“风口·浪尖” 当下,快节奏与高压力导致的人群健康问题日益突出,加之人口老龄化等因素的影响,医疗行业供给侧的短板难以应对需求端的增长。线下医疗除了资源分配不均衡的问题,公立医院的就医体验一直被患者所诟病。不可否认的是,在线医疗模式打破了医疗资源的空间局限,在缓解看病难,提升医患沟通体验,以及帮助优质医疗资源优化分配等方面,能够起到一定的积极作用。正是看到了巨大的供给侧缺口以及在线医疗的正向价值,从2014年开始,BAT以及众多的机构纷纷通过资本运作布局,在线医疗成为新的“风口”。 另一方面,在线医疗之路走的颇有一些“路漫漫其修远兮”的意味。每一次的热度都将它推上“浪尖”。在线医疗不只是面临着监管、患者信任、盈利模式等方面的考验,技术门槛高、产品上线慢 、模式突破难,也使得在线医疗一直游走于线下医疗的边缘。幸运的是,第三方云服务模式和机构的介入,正在加速这一领域的创新步伐,让在线医疗的探索可以“轻装上阵”,甚至小步快跑起来。   拒绝浮躁  可靠的云服务让行业未来可期 每个行业的革新和转型都不是一朝一夕的,尤其是对于医疗行业,涉及民生健康大业,国家和百姓关注度高,需要去除资本表面的浮华,踏实走好每一步。对于在线医疗产品本身,尤其是远程问诊类平台而言,社交和视频通话功能已是刚需。其中,稳定可靠的架构、流畅的视频通话、安全的存储等要求都是此类产品的核心诉求,需要专业团队针对性地打磨技术,并将服务细致化。只有资源和技术同时“在线”,才能让概念落地,让行业未来可期。 作为国内领先的即时通讯与音视频技术厂商,网易云信体察到在线医疗领域对音视频技术的迫切需求,持续探索将PaaS云服务模式与在线医疗场景深度结合,为其提供稳定可靠且性能卓越的IM和音视频的底层技术支持。首先,拥有亿级架构能力的网易云信IM云可以承载高并发、高实时的信息点对点、多对多传输。视频云可承载多种方式视频流媒体的传输和海量分发,满足了在线医疗场景中的沟通这一核心诉求。其次,针对医疗服务的特殊性要求,网易云信实现了包括多终端访问、文档共享、自定义消息、语音识别等丰富功能,并且可提供弱网优化等策略的针对调整,还有足够强大且安全的数据库保护患者隐私并保证问诊全过程可追溯,以满足合规的硬性要求。   携手并进  网易云信三年深入探索在线医疗 和缓医疗专注于慢性病及康复管理,可同时覆盖B端和C端。通过接入网易云信的云服务,和缓视频医生App具备了强大的即时通讯与音视频能力。视频通话的同时,医生可通过接收患者上传的化验单图片,查看患者病历记录来辅助诊断。诊疗全程进行音视频混录,确保过程的可监控和可追溯。网易云信团队提供的解决方案不仅理顺了诊疗流程,也让医患双方均获得了高于面诊的使用体验。 图:和缓视频医生移动端界面   乐普医疗集团旗下的乐普心脑血管网络医院联合了国内知名三甲医院的专家资源,以互联网的方式提供在线问诊、慢病随访、健康咨询等服务,让患者不出社区也能看上知名专家。网易云信帮助乐普网络医院实现了以北京为坐诊中心,覆盖全国的远程视频看诊。鉴于偏远地区网络信号差的状况,技术团队通过部署全球节点优化通讯传输质量,提供了抗800ms的网络抖动和抗30%网络丢包技术优化。 图:乐普网络医院解决方案流程架构   快速问医生是一款医疗健康手机应用,患者通过手机可快速咨询全国各地有资质的专业医生。依托于网易云信的PaaS服务,产品实现了点对点在线健康咨询,群聊互动交流功能,以及自定义消息的医生评价等功能。此外,依托于网易云信的语音识别技术,大片段的语音识别减少了用户靠文本输入进行沟通的不便,成为了该软件的一大功能卖点。 图:快速问医生移动端界面   最后,一组数据表明,网易云信已为超过120家医疗机构提供相应的技术服务,使医生工作效率提高150%、患者看病时间减少70%。网易云信相信,在线医疗是有价值的探索。以精益求精的态度和扎实的技术能力让在线医疗的优势落到实处,进而助力这个利国利民行业的长足发展,是作为技术赋能者的使命与价值所在。

2018-11-19

编解码器之战:AV1、HEVC、VP9和VVC

视频Codec专家Jan Ozer在Streaming Media West上主持了一场开放论坛,邀请百余名观众参与热门Codec的各项优势与短板。本文整理了讨论的主要成果,基本代表了AV1、HEVC、VP9和VVC主流的观点。 一百余个观众分为五组,分别代表H.264,VP9,HEVC,AV1和VVC编解码器。这五个小组分别由Harmonic视频策略副总裁Thierry Fautier(H.264),Facebook Video的Colleen Henry(VP9,代表其本人观点,并代表Facebook),Beamr战略副总裁Tom Vaughan(HEVC)、Bitmovin编解码工程师Christian Feldmann(AV1)和NGCodec首席执行官Oliver Gunasekara(VVC)领导。需要注意的是,组长在某种程度上是随机分配的,并不一定意味着对特定编解码器的提供更强支持。 最初,这些小组将根据图一定义的特征对每个编解码器进行排名。 图1.我们根据这些特征对编解码器进行了排名。 在小组讨论期间,用户们可以分享他们使用不同技术的经验并提出问题。在讨论结束时,每个小组的主持人通过采用编解码器的最强商业案例确定此编解码器的市场。 图3.编解码器记分卡 图3展示了该活动的记分卡,虽然有少数的意料之外,但很多类别都是从主持人或参会者那里获得新信息。 例如,就第一个类别编码性能来说(实际上应该称为编码时间,而不是性能),一位来自YouTube的编码工程师说,曾经AV1的编码时间是VP9的16倍,几周之前有报告显示其编码时间相比1000x+有明显的下降。尽管AV1仍然在此标准中排名最后,但这也是对编码时间提升的真实的证明。 在解码性能方面,一位参会者报告说,一家大型社交媒体公司已经使用该公司iOS和Android应用程序中包含的解码器,将AV1流发送给移动端观众并进行高效播放。我也分享了我的发现,Chrome和Firefox在单CPU HP ZBook笔记本电脑上播放1080p视频,占用了15%到20%的CPU资源。至少从编码时间和解码性能的角度来看,这些讨论缓和了关于配置AV1的两个初始矛盾。 然而,下一个类别提出了有关AV1压缩效率的重大问题,Fautier透露说,对Harmonic赞助的编解码器评估发现,AV1与HEVC有相似的压缩效率,这与BBC和编码供应商ATEME的调查结果类似。 关于HEVC和AV1的比较效率进行了大量的动画讨论,你可以看到图2中的阵容之间的差异,其中HEVC远远领先于VP9,以及图3中的结论。尽管该团队善意地确定了同等质量,大多数(但不是全部)第三方分析 评估表示HEVC在这方面表现更好。虽然该组中有一些人认为AV1优于HEVC和VP9,尽管这项技术至少还需要两年时间完成,但他们也同意它落后于VVC。 IP框架涉及许可结构,其中像VP9和AV1这样的开源免版税编解码器具有明显的优势。 虽然一些观众认为AV1可能会遇到IP索赔的挑战,但这些担忧被开放媒体联盟建立的知识产权防御基金以及成员公司的庞大规模和技术精湛所抵消。该组织中的大多数人似乎同意,实施VP9的公司几乎没有任何与知识产权相关的诉讼或质疑的风险。 虽然HEVC许可结构受到广泛批评,但少数观众认为批评过于夸张。一位参会者评论说HEVC与杜比音频等其他技术的版税率相当。许多人一致认为,尽管HEVC许可模式对于像浏览器这样的免费分发软件具有挑战性,但它适用于硬件设备,其成本可以传递给最终买家。 记分卡上接下来的内容是解码器的安装基础,H.264因其几乎无处不在地播放而轻松获胜。接下来是VP9,除Safari之外的所有主流浏览器都播放,大多数主要平台包括连接电视,机顶盒和OTT设备(如Roku 4)的份额越来越大。虽然VP9不能在iOS或Apple TV设备上本地播放,但可以通过应用程序提供基于软件的播放。当你有一个像YouTube或Netflix这样的必备应用时,这种方法很有效,但对于那些普及程度较低的小公司的应用而言,它可能并不适用。 虽然有一些第三方尝试在AppleTV设备上部署VP9解码器,但据报道4K AppleTV只能以1080P或更低的分辨率显示YouTube,这可能意味着若没有VP9的播放这就可能是一个非常好的分布式Apple TV应用程序。 尽管如此,可用于VP9的平台远远超过可用于HEVC的平台,后者在Chrome和Firefox中缺乏播放支持,但在可以在Android和iOS设备上播放,也可在几乎所有STB上、联网电视和当前型号的OTT设备如Roku 4,以及大多数当前Windows计算机和所有Mac上的本机浏览器上播放。正如一位参会者指出的那样,几乎所有的HEVC播放都是通过硬件完成的,这比基于软件的播放更加节省CPU /电池电量,并且能不断的提供高品质体验。 虽然AV1在某些平台上支持最新版本的Firefox和Chrome,但AV1几乎不怎么出现,因此不享受基于硬件的播放。如上所述,一家著名的社交媒体公司已经将AV1流发送给移动用户,以便通过其iOS或Android应用程序进行播放。如果AV1可达到承诺的20%到30%的编码效率,那么你会期望许多类似的大型公司也能这样做。显然,由于它尚未以任何形式发布,VVC排名最后。 最后一个特征是生态系统的采用,它测量了可用硬件和软件编码/解码实现的范围,包括贡献、实时编码以及对非流媒体应用的支持,如安全性,低延迟和军事。在这个方面,H264仍然占主导地位,由于解码选项的范围VP9排名第二。然而,大多数小组成员期望,现有的HEVC直播编码器和相机编码器等多种设备上非流媒体应用程序可以从H.264迁移到HEVC,同时这些设备完全不支持VP9。AV1和VVC都排在最后,因为这两种技术都没有硬件选项。 展望未来,H.264倡导者预测,虽然H.264将在流媒体市场中失去份额,但在需要在合理比特率下高质量、低延迟视频、合理的解码要求以及费用合理的非流媒体市场上仍有增长空间。HEVC倡导者认为,HEVC的使用在分配到OTT和连接的电视设备方面占主导地位,HEVC通过HLS分发到Apple台式机,移动设备和AppleTV 4K。 VP9似乎注定要用于OTT和UGC市场的大批量长尾内容,AV1在短期到中期都取得了成功。VVC太遥远了无法预测。 总结 对我来说,与AV1相关的最重要的收获是,这似乎比六周前更接近部署。编码效率仍然存在疑问,但随着实际部署的发生,我们将在未来几个月内了解更多信息。同样有趣的是,除了联网电视和类似市场之外,HEVC注定要接替H264作为各种非流媒体市场的首选编码解码器,如相机编码器,在安全性、贡献性等方面也有更好的性能,在这些方面VP9不太可能发挥作用。 有关VVC的一个重要问题是,IP所有者是否能够以具有竞争力的价格共同提供全包特许权使用费套餐。虽然MC-IF提供了一些希望,但它显然无权决定这一结果。 文 / Jan Ozer 译 / 咪宝 转载自LiveVideoStack公众号

2018-11-19

谈谈接入各种第三方推送平台的技术方案和一点经验

在移动互联网时代,为了运营好一个APP,消息推送是一个优质廉价的渠道。消息推送的使用场景简单来说,可以包括运营类的消息推送,如活动推广期间的推送等,还包括通知类的消息推送,如社交场景中的新消息提醒等。 对于APP来说,消息推送能够起到内容告知、提高日活,甚至召回用户的作用。那么如何接入第三方推送平台呢?本篇文章中,网易云信资深研发工程师将和大家聊聊接入各种第三方推送平台的技术方案,分享接入推送平台的一些实用经验。   如何接入第三方推送 推送的一般流程 推送是一种服务器主动push消息到设备端的行为,因此依赖于设备端和服务器的长连接。整体的架构和流程如下: 具体如下: 设备和推送服务器建立长连接 设备会根据某些规则生成或从推送服务器获取到一个DeviceToken,推送服务器可以根据DeviceToken定位到具体的设备 设备会上报DeviceToken到应用服务器(由应用自己完成) 应用服务器根据需要调用推送的服务端接口发起推送 推送服务器收到推送请求,根据请求中的DeviceToken定位到具体的设备,下发推送通知 设备收到推送消息,可以进行通知栏弹窗或者其他行为 IOS 苹果官方提供了APNS推送,有很高的推送送达率。早先的APNS推送提供了一套基于TCP协议的接口,但是该接口使用方式比较复杂,稍有不慎就会导致推送失败,但调用方还误以为推送成功。 后来苹果又提供了一套新的基于HTTP2协议的接口,新接口的一个好处是可以追踪到每个推送请求是被APNS服务器拒绝了还是成功了,再也不用去猜请求到底是被苹果服务器给丢了还是接受了。 安卓 谷歌官方最早提供了GCM推送,后来又推出了FCM推送来代替GCM,但由于国内的环境不适合使用,因此各个手机厂商又相继推出了各自的推送,推送的原理都是类似的,都是依赖于设备和推送服务器的长连接,但是厂商推送的优势在于这样的长连接可以和自己的手机系统绑定到一起,从而可以不同应用共享同一条长连接,节省了心跳的流量消耗,并且这样的系统级长连接可以不用担心应用被杀导致的应用内长连接断连导致消息推送不可达。 目前已经推出厂商推送的包括小米、华为、魅族、OPPO等,FCM也可以算安装了谷歌服务的设备的系统级推送。 不同于IOS,安卓阵营的推送服务器接口都是HTTPS接口,并且通过SecretKey的方式来进行安全校验。   一点经验 DeviceToken的管理 我们知道DeviceToken标识了一台具体的设备,但是推送服务本身是不知道应用本身的账号体系的,因此同一个APP,假设注销了A账号,改用B账号登录,此时DeviceToken一般来说是没有变化的,此时应用服务器需要去标识A账号的该设备属于注销状态,不然一条针对A账号的推送消息就会被B账号收到。 应用被卸载的情况 应用被卸载的时候(这时候登录的A账号),应用本身感知不到,此时针对A账号的该设备的推送还是会发出去,推送服务器收到推送消息,找不到对应的设备,此时没有问题,只是会消耗一些资源。假设此时设备上的应用又重新安装了,然后登录了另一个账号B,假设DeviceToken没有变化,此时针对A账号的推送将会被B账号收到。上面这种情况出现的前提条件是DeviceToken没有发生变化,测试发现华为推送存在这个问题(经过询问华为推送技术支持,2018年3月之后的设备不存在该问题),其他推送没有。为了解决这个问题,服务器必须自己管理DeviceToken-用户账号的映射关系,并在发现有DeviceToken冲突的情况下去把老的账号设置为注销状态。 IM场景下推送时机问题 IM场景下,应用服务器有自己长连接服务,此时第三方推送服务的作用是利用第三方厂商推送的系统级长连接来提高消息推送的送达率。 首先对于IOS端,应用无法常驻后台,我们会在应用切换前后台的时候通过IM长连接发送一个标记位,服务器会在设备离线或者处于后台的情况下触发APNS推送,从而减少设备在前台情况下APNS推送的流量消耗。 而对于安卓端,服务器会在设备处于离线的情况下触发第三方推送,否则会走IM长连接下发通知,当设备处于后台但还活着的时候,会在收到消息之后主动弹窗以便提醒用户有新消息。对于安卓端还有一个场景是这样的,安卓端在后台的某个时刻进程死了,此时过来一条需要推送的消息,服务器发现设备处于离线状态,尝试调用第三方推送(可能有也可能没有)。过了一会进程自己活回来了,重新连接到了IM服务器,拿到了未读消息,此时一般的逻辑下,进程会主动弹窗告知有消息到达,造成设备端的通知栏有两条推送。为了解决这个问题,需要IM服务器在设备重连的时候下发未读消息是否需要弹窗的信息。  

2018-11-19

浅析为何使用融合CDN是大趋势?

使用传统CDN的用户遇到的新问题 随着云计算时代的快速发展,尤其是流媒体大视频时代的到来,用户在是使用过往CDN节点资源调配将面临很多问题: 问题1: 流媒体时代不局限于静态内容分发,直播点播等视频服务对时延极其敏感,CDN资源的充足已经不足以解决低时延问题。 问题2: 传统CDN厂商为了控制成本,在四五线城市的边缘节点都会选择相对便宜的机房,这意味着可靠性和可控性的降低。从容量、服务稳定性、成本等各个方面来评估,传统CDN服务一般会采用一主多备,主要的CDN流量消耗在主方,一但主方有故障,则切到备方。这种模式,进一步导致了使用弊端的产生,即调度空间有限、稳定性差、管理成本高。怎么合理的利用多个CDN厂家资源,智能调度以及如何与业务进行更好地结合,在使用和接入上既可以简单易用又可以支撑业务敏捷开发会是难题。 问题3: CDN厂商在不断以技术以及资源手段打破限制,但与此同时,因为竞争,单独CDN厂商的资源相对封闭,对行业发展本身造成了限制和瓶颈。 智能融合CDN 选择以及场景使用 中国的CDN发展始于2003年,目前市场上厂家众多,传统CDN厂商和云CDN厂商占了大多数,而智能融合CDN是在近几年才发展出来。融合CDN存在的逻辑就在于能够打破单个CDN厂商的节点资源以及调度能力,突破地域时间以及不同运营商的限制。通过技术手段融合多个CDN厂商资源,或者再结合上自有CDN资源,通过强大的智能调度策略来综合利用上述资源来解决实际场景中的问题。 其背后包含着CDN基础设施建设、全链路的网络质量监控、精确智能的调度和高效的容灾、极致的性能体验、高性价比的成本等等,当然最重要的是能够解决实际场景中面临的问题,能够为相关的业务提供帮助,这个就因场景和业务而异了。事实上,智能融合CDN概念的内涵也是在不断变化和演进的,现在意味着更加高效智能的资源利用和调度,全链路端到端的立体品控。近期,P2P、边缘计算等技术也不断的应用到CDN技术中,改变着CDN技术的发展,但始终不变的当然还是解决实际问题,万物为我所用,解决用户、场景实际问题。 通常来说,融合CDN带来更加大的带宽容量储备,结合精细化的链路控制、智能的调度、实时的分析和精细运营,可以带来更加优质的服务效果、更加稳定鲁棒的质量和相对降低服务成本。 智能融合CDN主要应用于大体量的应用或者平台,或解决自己产品在CDN加速方面对容量、灾备、效果、成本等方面的需求,这些需求往往既丰富又一定复杂度,同时又希望灵活易用的使用和接入方式,或是一些新兴的CDN供应商或者说参与者,凭借自己在品质控制、智能调度、精细运营等方面的优势,借助传统CDN厂商的资源优势,提供更加优质和易用的CDN服务。 如何选择融合CDN厂商 选择的三大标准:节点质量、技术指标以及服务支撑 事实上用户对CDN的要求并不是资源数量,而是最终使用的稳定性和高性能体现。无论是通过智能调度策略进行CDN资源调配使用户使用无感知,亦或者是在极端灾难情况下做到多CDN灾备,快速切换。还有带宽容量的灵活处理、全链路的监控等都会是选择融合CDN厂商的选择标准。 尤其是智能调度系统是否可以数据为基础,从可用性,性能,成本等多个维度对节点进行调度。保证每个终端用户在不同区域均获得最佳的性能。 目前国内很多销售员都会拿多节点数来忽悠人,而做CDN的公司大大小小上百家,鱼龙混杂,如果不摸清情况再选择,很容易买到既贵又不好用的CDN服务。 谈到技术指标数据,在测试时应该集中关注延时、卡顿率、下载速度、打开速度、宽带冗余提升率等数据。根据全球第三方测速的公司Gomez官方数据显示:当页面加载时间超过7秒后, 50%的用户会选择放弃,且每增加1秒的延迟会带来7%转换率的下降。一般情况,100K的网页素材加载总时间低于250ms算优质CDN。 服务支撑的选择也同样重要,在价格、技术指标以及服务模式三者综合比较下选择最高性价比模式。等性能得到保障之后,本身平台的监控水平,DNS调度能力,平台的本身系统的灵活性和可扩展能力都应该受到前期调研的关注。 网易云信全球智能融合CDN方案 网易云信全球智能融合CDN方案主要是面向视频云平台的场景和需求。视频云服务本身定位于向开发者提供一站式、端到端的音视频PaaS服务,基于云信音视频服务提供的客户端SDK以及开放API可以快速构建出一个直播、点播、实时音视频应用。网易云信通过融合CDN技术,结合全球多个节点资源,不仅将多CDN灾备、带宽容量、链路选择、智能调度、全链路监控等问题完美解决,向客户提供优质的音视频服务体验,而且做到使用和接入的简单易用。用户在使用云信视频云服务的过程中,不仅可以获得了网易云信端上的音视频编解码和推拉流能力、服务端的音视频处理能力,流媒体分发过程中的问题,也可以不用关注,全部细节都交给视频云平台的能力,用户只需享受端到端的优质音视频体验。

2018-11-19

浅谈实时音视频直播中直接影响用户体验的几项关键技术指标

前言 这两年互联网领域的一个热门关键词就是实时音视频直播,从刚开始的游戏直播和秀场娱乐开始,实时音视频直播带来了远超传统互动的用户体验,现在实时音视频直播已逐渐深入当今主流的互联网应用形态里。 本文将聊一聊实时音视频直播的几个关键技术: 清晰度: 4K、1080p、720p,这些概念被各大电视机厂商炒作了这么多年,已经地球人都懂了。4K在互联网视频直播里现在还不普及,主要是对网络数据传输要求太高了。1080p在一些对清晰度要求较高的场景如游戏直播里已经慢慢普及,要求的数据传输速率大约在4Mbps左右。720p是现在直播的主流清晰度,速率大约在1Mbps左右。在一些要求不太高的领域,还会有540p或者360p出现。 流畅度: 如果在直播时出现卡顿、转圈,就意味着不流畅。主播和观众的连接通道好比一根水管,流量是有限的,因此如果清晰度提升意味着观众收看直播的流畅度有可能会下降。 延时: 视频直播都是讲求互动性的,如果跟秀场妹妹聊天,讲了半天都没反应就略坑爹了。但是延时也不全是坏处,适当的延迟意味着在观众端能够有一定的视频流数据缓存,当出现网络不稳定时能够抵御小范围波动而使得观众无感知。 首屏时间: 当观众进入直播间算起,到出现第一个主播画面的时间叫做首屏时间。为了保证直播流畅,会缓存一段数据之后再开始播放,但这个也不是绝对的,后文会详细描述。 下面,我们将逐一分析和总结实时音视频直播中的这几个重要技术指标。 首屏秒开 先从观众进入直播间那一刻说起,这相当于整个直播生命周期的开始。当进入直播间后,播放器会向CDN请求数据。此时,假设主播已经发送视频流数据到了第100帧,由于数据传输的一些延时,CDN端最新收到的数据可能在第90帧。当CDN接收到拉取视频流请求时,他会做一件非常有意思的事情,即往前回溯一段数据,在图中显示的是回溯2秒钟,那就到了视频流的第五帧。CDN会把第五帧开始往后的数据,通过RTMP或其他直播协议源源不断的发送到播放器。那为什么要往回2秒钟呢,这可能算是目前视频直播技术中一个比较有特点的技术优化,能用于很好地平衡流畅度和首屏秒开时间。具体运作机制我们接下来再看。 流畅播放 接下去发生的事情,很好地可以说明回退2秒的作用。因为CDN是从第5帧开始发送数据,之后的数据全部缓存在CDN服务器中,因此可以源源不断地把数据发送到客户端,图中显示了从第5帧到50帧之间的数据,全部缓存在播放器内存中。这部分数据可以用于有效的抵抗网络波动造成的影响。当然,这样做的一个缺点是播放器相比于主播,延迟时间增加了2秒。所以说,视频直播所做的事情,就是在延时和流畅度之间找到一个很好的平衡点。 网络拥塞 网络拥塞是互联网上最常见的一个情景,接下去讨论当发生网络拥塞时发生的情景。假设当观众播放到第150帧时,用户下行网络出现问题,如果播放器没有新的数据到来,必然会画面卡住并开始转菊花。而此时,主播端并不会感知到这个事情,主播还在正常推送视频流数据。在经过了大概4秒左右的卡顿后,观众端的网络恢复,数据又会源源不断从CDN流向播放器。在图中看到网络流畅时,播放器的缓存中已经存放了第280帧数据,此时当前画面是150帧。这会产生一个什么问题?因为播放器播放数据是按照每一帧的时间戳匀速播放,因此如果不做任何优化就意味着每经过一次卡顿,直播的延迟就会增加一段时间,而增加的时间和被卡住的时间是一致的。 延时追赶 经过刚刚的描述,大家一定已经明白了延时累加是一个必须解决的问题。因此,播放器还需要做的事情就是延时追赶。播放器必须要实时侦测缓存中数据的情况,一旦大于某一阈值就启动延时追赶。追赶的方式,可以是直接扔掉多余数据也可以采用快进方式。快进模式相对来说用户体验会好一些,不会产生明显跳跃,处理时要注意声音不要因为快进而产生尖刺。最后再提一下,延时追赶不能太激进,还是应该在缓存中留一段数据,用于缓解以后可能再次发生的网络拥塞。 小结 前文描述了首屏启动、流畅播放、网络拥塞、延时追赶的基本概念和每个阶段内部所发生的事情,整个直播就在流畅、拥塞和延时追赶三个阶段中来回往复。看完本文,有兴趣读者可以尝试利用开源软件自己去写个直播APP,可以拿来练手娱乐,如果要上线还有各种其他奇葩的坑。 (原文链接:https://mp.weixin.qq.com/s?__biz=MzI0MjEwNTUyOA==&mid=2650030540&idx=1&sn=367f15a95d1c3808dd1f21de983df2df&chksm=f1018c1bc676050d17ea9feac5f3f06436fc1fe4c6998931b7e48c1f3c6996614fad8b3eae05&scene=0&key=f28c980717f90f964a69a47e8a521d866a7911fa31ddd170d9f175eb98acbb0a75475f7e0ad18f25a012de224572f7174ef85f648de51df9cac0d833308c13b6bcf79a431b64d910aa414e622b4314a6&ascene=0&uin=MTQ5NTk2Nzc0Mg%3D%3D&devicetype=iMac+MacBookPro11%2C1+OSX+OSX+10.11.6+build(15G31)&version=12020010&nettype=WIFI&fontScale=100&pass_ticket=cP8JlUk29zesGv8rKs4VHWGRlvGg9xwXWDH%2B6zBp7uJS6yU1aIt9OaRgVwqgLa%2Bs) 来源:即时通讯网 - 即时通讯开发者社区!

2018-11-05

如何优化传输机制来实现实时音视频的超低延迟?

1、前言 要在语音视频 SDK 中实现超低延迟,实时的语音视频传输机制是必不可少的,而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石。 在语音社交、视频社交、游戏语音和互动直播等领域,关于在语音视频实时传输中实现低延迟这个议题,已经有不少的文章提出各种方案。绝大部分方案的思路都是“优化”,比如说,优化编码、推流、传输和播放等各个环节。 愚以为,要在实时语音视频传输中获得超低延迟,是不能单靠挖空心思去“优化”的,而是要依靠实时的传输机制。就像高铁和火车有着本质的区别一样,火车不管如何优化,也只是跑得更快的火车,永远达不到高铁的速度。没有一套实时的传输机制,再怎么在各个环节“优化”,也无法获得真正超低的延迟。 要实现超低延迟,信道 QoS 十分关键。首先要选择合适的网络传输协议,采用基于 UDP 的私有协议还是标准 RTMP 协议?然后根据网络环境采用合适的 QoS 技术,采用 FEC,ARQ,还是双管齐下? 如果采用 FEC 和 ARQ 双管齐下,那么一套智能的 QoS 策略就必不可少。没有任何一种 QoS 技术能解决所有问题,实时语音视频传输机制必须是多种 QoS 技术的有机结合。 2、传输层协议的选择 如果是视频直播 SDK,一般会选择 RTMP 协议,因为要能够普遍兼容 CDN 分发网络,从而向围观的广大用户进行直播。如果是音频社交 SDK、视频社交 SDK 或者游戏语音 SDK,一般会选择 RTP/RTCP 协议(或者类 RTP 的私有协议),因为不需要通过 CDN 网络向围观用户广播媒体流。是否要考虑兼容 CDN 网络,是语音视频通话 SDK 和视频直播 SDK 的重大区别。 RTMP 协议是基于 TCP 协议的,RTP 协议或者私有协议是基于 UDP 协议的,因此 RTMP 协议和 RTP 协议之争,本质就是 TCP 协议和 UDP 协议之争。 TCP 协议的特点: 1) 是通用的 IP 网络协议,不是为实时媒体传输而设计的,在弱网网络环境下延迟会增大; 2) 有内嵌的 ARQ,但没有 FEC,不允许开发者对 ARQ 策略进行控制,不能实现 FEC; 3) 不是从实时语音视频的角度进行设计的,更多考虑网络传输的公平性,内嵌的传输控制策略比较温和。 UDP 协议的特点: 1) 适合实时语音视频通讯,允许端到端全链条进行信道策略控制,在弱网环境下可控性更强; 2) 延迟时间的大小取决于丢包时候的 ARQ 和 FEC 策略,允许开发者深度控制 ARQ 和 FEC 策略; 3) 适合设计实时语音视频的通讯机制,根据网络状况自适应地选取 ARQ 和 FEC 策略,以及调整传输码率和报文的数量。 在网络环境好的情况下,只要语音视频编解码器相同,RTMP 协议和基于 UDP 的私有协议的传输效率是相当的,都可以实现低延迟、不卡顿和高品质的实时通讯效果。 在网络环境较差的情况下,特别是在跨网甚至跨国的情况下,基于 UDP 的私有协议对端到端全链条可控,包括流控码控、ARQ、FEC 和抖动缓冲等,对抗恶劣网络环境会更有保障。 3、信道保护 IP 网络是“尽力而为”地提供数据传输服务的,尽最大的可能性来发送报文,但对时延、可靠性等性能概不负责效果,传输的数据出错是避免不了的,因此对信道进行保护是必须的。 信道 QoS 技术主要包括前向纠错 FEC,丢包重传 ARQ 和混合型 ARQ。这几种算法都是成熟的技术,在最基础的算法上又衍生出多个变种,而且在实现的过程中也可以进行定制化。 在 FEC 和 ARQ 的基础上,为了更好地适应弱网环境,需要让码率自动适应网络环境的波动,这样能够更好地保障实时语音视频通话的可用性和流畅性。   ▲ 信道 QoS 的三大措施 1前向纠错 FEC FEC 全称是 Forward Error Correction,中文翻译为前向纠错,是一种通过增加冗余数据对丢失的数据包进行恢复的信道编码算法。具体地说,由发送端对原始数据进行 FEC 编码,生成冗余奇偶校验数据包,原始数据和冗余数据包合并称作 FEC 数据块,原始数据包和冗余数据包的数量比例是固定的。发送端发送 FEC 数据块。接收端接收到 FEC 数据块后,通过冗余数据包和原始数据包来恢复出丢失或者出错的数据包。 FEC 编解码算法推荐使用比较成熟的 RS(Reeds-Solomon) 算法、Raptor 算法和 Tornado 算法。使用 FEC 编码算法的时候要根据丢包率(PLR, Packet Lost Rate)来设置冗余度。 下面使用 RS 的一个例子来说明 FEC 编解码算法的使用方法。 因为在一个 FEC 数据块中,原始数据包的个数和冗余数据包的个数的比例是固定的,所以很容易根据丢包的个数和冗余包的个数来判断是否能够全部恢复丢失的数据包。RS (n, k) 表示通过 RS 算法把 k 个原始数据包进行编码,生成(n-k)个冗余数据包,总共是一个包含有 n 个数据包的 FEC 数据块。假设丢失了 m 个数据包,如果 m<=(n-k),那么 RS 算法可以完全恢复丢失的数据包;如果 m>(n-k),那么 RS 算法就无法恢复丢失的数据包,这时候就要进行发送请求要求重传丢失的数据包。 下图展示了通过 RS(6,4) 进行丢包恢复的过程。发送端有 4 个原始数据包,通过 RS 算法编码生成 2 个冗余包,形成了一个拥有 6 个数据包的 FEC 数据块。RS 算法最多能够恢复 2 个丢失的数据包。发送端把 FEC 数据块发出去,在传输过程中第 2 号原始数据包丢失了。接收端接收到 FEC 数据块以后,通过 r1 冗余包把已经丢失的第 2 号原始数据包恢复出来。 ▲ RS(6,4) 算法恢复出丢失的数据包 使用前向纠错 FEC 算法,优点是数据包只需要传输一次,传输延迟不会受到 RTT(Round Trip Time) 的影响,不会增加额外的延迟时间;缺点是需要增加冗余数据包,降低了传输信道的利用率。总的来说是一种“空间换时间”的策略。 下文将会综合对 FEC 和 ARQ 的特点进行全面对比。 2丢包重传 ARQ ARQ 全称 Automatic Repeat reQuest,中文意译为丢包重传,是一种通过重传关键数据包来纠错的信道保护算法。 具体地来说,发送端给每一个数据包都植入顺序号码和时间戳,顺序号码代表被发送数据包的顺序,允许接收端可以通过监测顺序号码来发现丢包事件;时间戳代表语音视频数据包解码的时间点。发送端发送数据包后,如果接收端没有收到,接收端将会通过 RTCP/TCP 信道发送一个重传请求。发送端维护一个缓冲队列,当收到重传请求的时候将会重传数据包。接收端也会维护一个缓冲队列,等待尚未收到的数据包以及对已经收到的数据包进行排序。在解码的 deadline 到来之前,接收端把缓冲区的数据包交给解码器进行解码。在解码 deadline 的时间点,接收端要么已经收齐了预期的数据包,要么已经决定放弃继续等待。 传统的丢包重传 ARQ 包括以下三种: 1)Stop-and-wait ARQ,也就是停止等待的 ARQ,发送端发送数据包后就停止并等待接收端的确认消息,在收到确认消息之前,信道处于空闲状态; 2)Go-Back-N ARQ, 也就是退回 N 步的 ARQ,发送端不需等待接收端的确认,不停地发送数据包,直到收到接收端的重传请求。发送端除了重传被要求重传的数据包以外,还会把该数据包时间戳后面已经被接收端成功接收到的一批数据包全部重传一遍; 3)Selective Repeat ARQ,也就是选择性重传的 ARQ,发送端不需等待接收端的确认,不停地发送数据包;接收端只会有选择性地对关键的数据包要求重传,而发送端只重传被要求重传的数据包。 第一种和第二种 ARQ 效率比较低下,第三种 ARQ 相对来说效率比较高。目前主流的丢包重传算法大部分是第三种 ARQ 的变种或者定制化版本。 选择性重传 ARQ 的优越性在于它能确定哪些关键的数据包需要重传,从而大大地提高重传的效率,降低造成重传风暴的风险。比如说,在出现花屏的时候,请求发送端立即编码视频关键帧发送过来,避免长时间花屏无法刷新的现象。选择要重传的数据包的算法十分关键,这里必须要有比较谨慎的策略,不能任何丢失的数据包都要求重传,那样就相当于又走了 TCP 协议内嵌 ARQ 模块的老路,必然引入不可控的延时。 选择性重传的 ARQ 要考虑实时性,要估算计划要重传数据包到达的时间(以 RTT 的倍数来估算),如果数据包预期的到达时间在解码的 deadline 之前,就要求重传,如果在 deadline 之后,就放弃重传。下面通过一个例子来说明选择性重传的 ARQ 这个实时策略。 下图展示了选择性重传的 ARQ 的实时策略: 1)发送端发送 #1、#2 和 #3 三个数据包,数据包 #2 丢失了; 2)N 倍 RTT<数据包 #2 解码 deadline, N=2,判断可以接受重传 2 次; 3)接收端通过 RTCP/TCP 信道请求重传; 4)发送端重传,数据包 #2 再次丢失; 5)接收端通过 RTCP/TCP 信道请求重传; 6)发送端重传,数据包 #2 成功到达; 7)接收端把 #1、#2 和 #3 三个数据包排序,交给解码器解码。 ▲ 选择性重传 ARQ 考虑 RTT 和编码 deadline 等实时因素 如果在 2 次以内能重传成功,那么就可以缩短接收端的缓冲时间,在解码 deadline 之前把数据包排序并交给解码器解码。如果在 2 次内不能重传成功,那么就放弃继续重传。因此,接收端总能维持解码的时间 t<= 解码 deadline,维持了传输的实时性。 使用选择性重传的 ARQ 算法,优点是只需要有选择性地传输关键的数据包,不会明显增加额外的带宽,带宽利用率十分高;缺点是需要请求和重传,增加了传输延迟时间。总的来说是一种“时间换空间”的策略。 下表对 FEC 和 ARQ 的特点进行综合对比。 ▲ FEC 和 ARQ 的特点对比 3码率自适应 ABC ABC 全称 Adaptive Bit-rate Control,中文意译为码率自适应,是服务端和推流端协作控制码率来自动适应网络环境变化的技术。码率自适应的目的是为了对抗弱网环境。在网络好的情况下,适当提高码率,提高语音视频的质量和降低延迟;在网络差的情况下,适当降低码率,保障语音视频通话的可用性和流畅性,适当牺牲音画质量。 码率自适应包含了带宽估算和码率控制: 1)带宽估算,服务端和推流端协作完成,推流端把网络环境统计信息上报给服务端,服务端通过带宽估算算法估计出当前带宽; 2)推流端按照估算出来的带宽进行推流,如果网络情况良好(没有检测到网络拥塞)则持续的地提高码率,试探网络带宽的上限,直到出现网络拥塞为止; 3)当网络拥塞出现的时候,推流端降低码率来保障可用性和流畅性,直到网络拥塞缓解为止; 4)当网络拥塞缓解的时候,转到 #2。 整个过程可以类比成驾驶汽车过程中控制方向盘的方法,偏左了就往右边调整一点,偏右了就往左边调整一点,来来回回的微调让驾驶处于安全和顺畅的状态。码率自适应也是一样的道理。 4错误隐藏 PLC PLC 全称 Packet Lost Concealment, 意译为错误隐藏,应用于实时语音通话的场景。语音数据包的丢失会造成语音的歪曲。为了减少语音数据包丢失造成对语音通话质量的伤害,错误隐藏 PLC 算法通过前一个语音数据包和后一个语音数据包的相关性来“推测出”当前丢失的语音数据包,从而“隐藏”了信道传输所造成的错误。错误隐藏 PLC 算法在接收端进行,不需要发送端参与。 4、智能 QoS 上面介绍了信道保护的各种 QoS 算法。没有哪一种算法能够解决所有问题,也不是把所有算法一起混着用就能实现通讯机制。如何综合使用这些算法对信道进行保护从而达到实时的效果?这里需要一套智能的 QoS 策略,既要能对抗网络损伤,又要能保持媒体数据传输的实时性。 1混合 FEC&ARQ FEC 和 ARQ 各有各的优点和缺点。FEC 虽然不会增加额外的延迟,但是会增加额外的带宽成本。ARQ 虽然算法相对简单而且几乎不增加带宽成本,但是会增加额外的延迟。因此,一般的做法是把 FEC 和 ARQ 混着通过智能的策略来使用,也就是混合型 HARQ(Hybrid ARQ)。 混合型 HARQ 的智能策略要充分考虑网络情况,也就是要根据 RTT 和 PLR 的数值来智能地决定使用 FEC 还是 ARQ,还是两者一起使用,哪个用多一点哪个用少一点? 下图是笔者和团队在工作经验中总结,仅供参考。 ▲ 即构的智能 HARQ 策略 上图中有三块区域,代表两个极端情形和一个中间情形: 1)较弱网络的极端情形:在 RTT>250ms 或者 PLR>10%, 网络延迟特别大或者丢包率特别高的情况下(蓝白色区域),不使用 ARQ 而使用 FEC,因为在延迟大或者丢包多的弱网情况下,ARQ 可能会进一步加大延迟; 2)较好网络的极端情形:在 RTT<70ms 或者 PLR<3%,网络延迟很小并且丢包率比较低的情况下(深蓝色区域),适合使用 ARQ,如果对成本不敏感,可以适当使用 FEC; 3)中间的情形:在 (RTT<=250ms 而且 PLR<=10%) 的前提下,RTT>=70ms 或者 PLR>=3% 的情况,可以根据成本和体验的考虑,智能地选择使用 FEC 和 ARQ 的权重。 语音数据可以适当地通过 PLC 来恢复,可以减低延迟时间和带宽成本。另外,由于语音数据比起视频数据小好多,与其通过 FEC 和 ARQ 复杂的算法处理,还不如在适当的网络情况下,在一定的时间间隔内发送两次同样的语音数据包,从而达到用冗余数据纠错的效果。 2带宽估算 无论是码率自适应、FEC 还是 ARQ,都要依赖带宽估算算法来工作。码率自适应根据带宽估算的结果来自动调节码率;FEC 和 ARQ 根据带宽估算的结果来分配冗余数据所占的带宽。 发送端和服务端协同对网络带宽进行检测和估算,发送端把网络带宽的统计信息上报给服务端,服务端把网络带宽的估算结果反馈给发送端。当然,也可以完全在推送端进行带宽估算。 除了带宽估算以外,网络拥塞探测对码率自适应也十分关键。比较传统的网络拥塞探测算法是根据网络丢包率来探测网络拥塞的。然而,当发生较大规模丢包的时候才提示网络拥塞,网络拥塞已经发生了,这时候才来调整码率已经太晚了。 拿地震预报举例子。如果等到发现桌子电灯摇晃的时候才“预报”说有地震,“预报”的时机太晚了。如果发现老鼠或者飞禽逃走等异常情况,或者探测到地震波,就真正做到预报地震。 现代的网络拥塞算法也是力求做到预报拥塞的效果。一般的做法是,发送端发送一些探测数据包,接收端监控数据包的延迟时间和缓冲队列长度。当探测数据包经过网络拥塞节点的时候,延迟时间会变长而且不稳定。如果发现探测数据包的延迟时间变大或者出现异常波动,或者缓冲队列变长了,那么网络拥塞很可能将要出现,相应地可以降低码率来适应网络情况的变化。另外,也有通过滤波器来进行网络拥塞预测,当滤波器的某些特征超过一定的阈值,就预示网络拥塞将要发生。 3带宽分配 码率自适应 ABC 模块估算出带宽以后,发送端把带宽分配给原始数据包、FEC 校验包和 ARQ 重传包,这里需要一个智能的带宽分配策略。带宽分配策略是根据网络情况,包括 RTT 和 PLR 等因素,来给原始数据包和冗余数据包分配带宽。冗余数据包的带宽分配得越多,QoS 信道保护算法的纠错能力就越强,然而原始数据包就相应分配得越少,语音视频的质量也就相对降低。相对而言,冗余数据包的带宽分配得越少,QoS 信道保护算法的纠错能力就越弱,然而原始数据包的带宽分配越多,语音视频的质量也就相对得到保障。因此,智能的带宽分配策略是要在语音视频的质量和 QoS 信道保护算法的纠错能力之间寻找平衡点。 一般来说,带宽分配的策略可以按照下面的方法进行: 1)总共的带宽由码率自适应 ABC 模块估算得出; 2)丢包重传 ARQ 的重传数据包所占带宽根据 RTT 和 PLR 估算得出; 3)前向纠错 FEC 的校验数据包所占带宽根据 RTT,ARQ 恢复后的 PLR,和总共的带宽估算得出; 4)原始数据包所占的带宽根据 ARQ、FEC 和总共的带宽计算得出。 下面是一个例子,展示随着 RTT 和 PLR 的增加,如何在原始数据包、ARQ 和 FEC 之间分配带宽。   ▲ 智能的带宽分配策略示例 上图中左边的坐标系中,纵坐标是带宽,横坐标是 RTT。在 RTT 比较小的网络情况下,ARQ 分配的带宽比较多,不采用 FEC;在 RTT 比较大的情况下,FEC 分配的带宽比较多,不采用 ARQ。不管使用 ARQ 还是 FEC 冗余数据包进行信道保护,原始语音视频数据所占的带宽都要适当牺牲。 上图中右边的坐标系中,纵坐标是带宽,横坐标是 PLR。在 PLR 比较小的网络情况下,ARQ 和 FEC 冗余包分配的带宽都比较小,甚至没有;在 PLR 比较大的网络情况下,逐渐给 ARQ 和 FEC 增加带宽来增强数据纠错能力,原始语音视频数据所占的带宽也相应降低。 5、本文小结 实时语音视频通话要获得超低延迟,不能仅仅依靠在各个环节不断地优化,而是要通过 FEC、ARQ 和码率自适应构建实时通讯机制。在这个基础上,还要充分考虑网络情况、实时要求和成本因素,以及需要大量经验数据的支撑(比如说,PLR 和 RTT 的关键阈值等)。要比较妥善的做到上面的要求,对语音视频技术团队绝对是一个严峻的考验。 (原文链接:有改动,https://mp.weixin.qq.com/s/ePmKVah1CbXdueHEW8n0vw) 来源:即时通讯网 - 即时通讯开发者社区!

2018-11-05