网站地图 | RSS订阅 老铁博客 - 上海SEO优化|上海网站建设|蜘蛛池出租|站群代搭建
你的位置:首页 » 网站建设 » 正文

新增小程序直播、WebRTC实时语音等多项能力即构音视频SDK再升级

2019-8-4 1:29:46 | 作者:老铁SEO | 0个评论 | 人浏览

  经过2018年小半年的闭关练功,即构ZEGO团队铸造了不少黑科技。本文将为你带来即构ZEGO实时语音视频SDK近半年新增能力和功能优化的最新进展。

  作为全球领先的实时语音视频服务,即构ZEGO主要通过两种方式向市场提供服务:

  (1)即构ZEGO实时语音视频SDK,包括实时语音SDK和实时视频SDK;

  当前,即构的实时音视频能力已经广泛应用到视频直播、音视频通话、在线课堂、游戏音视频、视频会议、呼叫中心、在线医疗和视频物联网等多个场景之中。

  2018年小半年来,即构ZEGO实时音视频SDK陆续增加了以下新的能力:

  本地混音是指将几种不同的声音在发送端混在一起。例如常见的K歌场景,就需要将人唱歌的声音和歌曲的背景音乐进行混音处理。酷狗音乐的在线直播K歌使用了即构的解决方案,其中就应用到本地混音技术。

  在理解虚拟立体声之前,需要引入一个概念双声道。双声道是指有两个声音通道,其原理是人的耳朵可以根据左耳和右耳对声音的相位差来判断声源的具体位置,即听声辨位。

  虚拟立体声的实现是基于双声道的原理,将单声道的声音经过算法处理,虚拟成双声道的声音,这样就可以听声辨位。

  虚拟立体声最重要的一个应用场景是竞技类游戏。玩过CS的朋友都知道,在虚拟的游戏场景中,我们可以根据听到的其它玩家的脚步声来判断玩家的具体位置。这就是虚拟立体声技术的典型应用。

  声波在室内传播时,要被墙壁、天花板、地板等障碍物多次反射后才会逐渐消失。我们感觉到的声源停止发声后还有若干个声波混合持续一段时间(室内声源停止发声后仍然存在的声延续现象),而多个波形叠加在一起也会让声音听起来有空旷感,这种现象叫做混响,这段时间叫做混响时间(引自百度百科)。

  高水平的音乐会都不使用扩音设备,为的是使听众直接听到舞台上的声音。为了让全场听众都能听到较强的声音,音乐厅的天花板上挂着许多反射板,这些反射板的大小、形状、安放位置和角度都经过精确设计,以便把舞台上的声音反射到音乐厅的各个角落。

  在一些直播场景中,某些主播想要获得演唱会场中演唱的声音效果,就可以使用即构的混响技术,实现类似开阔场所的空旷音效。即构的混响技术通过把一个原始的波形数据虚拟成多个类似的波形数据,然后让它们在相位产生差异,模拟波形在市内传播和多次反射后的效果,最后把多个波形叠加在一起来形成混音的效果。

  人声的音域较窄,音乐声的音域则比较宽,两种声音使用的是不同的编解码器,同时带宽和采样率也不一样。音乐声和人声的切换意味着编解码器也需要切换。在直播的场景中,经常会出现主播一段时间说话一段时间唱歌的情况。即构的音视频技术可以实现音乐和人声的智能切换。

  全平台互通连麦有两层含义,第一层是指使用即构的SDK可以在原生APP、Web/H5浏览器、微信小程序各终端上实现连麦互动功能,第二层是指具备连麦互动功能的各个终端(APP、Web和小程序)还可以互通连麦。例如微信小程序用户可以与APP用户连麦,浏览器用户可以实现与小程序用户连麦、APP用户可以和浏览器用户连麦等。

  实现多种终端互通连麦的难点在于要在保证低延时流畅稳定的情况下,实现各种协议及媒体格式的转换。APP、Web、小程序,这三种终端采用的协议、媒体格式和信令都不尽相同:

  (a)微信小程序推拉流采用RTMP协议,视频格式采用H.264,音频格式采用AAC;

  (b)在浏览器端上实现连麦功能就要符合WebRTC规范,视频格式采用H.264,音频格式采用OPUS;

  (c)在原生APP上即构SDK支持基于UDP的私有协议和标准RTMP协议,视频和音频支持主流的格式。

  实现原生APP、小程序和浏览器的互通连麦需要通过网关(接入服务器)把协议、媒体格式甚至信令进行转换,最后接入到即构实时传输网络。这对系统架构的扩展性是一个非常大的考验。

  即构科技是业界第一家实现全平台互通连麦的实时音视频云服务商。即构灵活的系统架构可以方便企业快速接入新的终端类型,除此之外,全平台互通连麦还可以极大地方便企业在各平台上进行业务创新。

  即构的解决方案同时支持标准RTMP协议和基于UDP的私有协议进行连麦互动,客户在不同的场景下可以选择不同的协议:

  (c)基于UDP的私有协议具有较好的弱网抗性,在跨网、跨国和弱网情况下延迟和流畅性都会有较好的保障。

  如果终端是浏览器,那么可以通过RTMP协议、HTTP-FLV、HLS、WebSocket从CDN拉流观看;如果终端是APP,还可以直接地通过基于UDP的私有协议从低延迟网络拉流观看。这几种协议即构都支持,客户在不同的场景下可以选择不同的协议。

  常见的需要同时推两路视频流的场景有线上抓娃娃和游戏直播。线上抓娃娃需要同时推送两个角度的摄像头的视频流,游戏直播则需要同时推送游戏画面和主播画面两路流。

  这项技术允许在不少场景中实现信息和视频画面的同步。例如在直播答题场景中,将题目信息通过音视频通道来传输,可以巧妙地保证题目和视频画面严格同步。在K歌场景中,将歌词和直播画面信息一起传输,这样歌词和画面及声音就能严格同步。在视频会议中,将白板信息和直播画面同步传输,这样学生收到的老师的声音和画面就和白板上的笔画就同步了。

  针对主流游戏引擎深度优化,ZEGO即构提供与两大游戏引擎Unity和Cocos兼容的游戏语音开发接口,开发者拿到即构的SDK可以直接开发集成来获得游戏语音和视频通话能力。

  以上是截止到发文为止,即构ZEGO实时音视频SDK的新增能力和功能优化的具体细节信息。

  即构ZEGO团队将持续升级ZEGOSDK,为业界为用户打造更懂应用场景的语音视频云服务。我们也将会不定期地向大家同步最新的技术进展。

  即构科技于2015年由QQ前总经理林友尧创立,A轮获得IDG投资,核心团队来自腾讯QQ,汇聚了来自YY和华为等厂商的顶尖语音视频人才。即构ZEGO致力于提供全球最清晰最稳定的实时语音视频云服务,助力企业业务创新,改变用户线上沟通方式。即构ZEGO深耕视频直播、视频社交、游戏语音、线上抓娃娃和在线教育等领域,赢得了映客、花椒直播、一直播、喜马拉雅FM、陌陌游戏、自由之战2、和好未来等顶级厂商托付和信赖。

  下面是截止到2018年5月,即构ZEGO实时音视频SDK功能优化的其他细节信息。

  2)修复“开始拉流后,使用相同的StreamID重复拉流,SDK内部会重新拉流的Bug”,修改后的逻辑为“保持之前的拉流状态”

  1)开始一次推流后,如果没有向业务层通知过“推流成功“,则不会向业务层回调“推流重试事件”。

  2)开始一次拉流后,如果没有向业务层通知过“拉流成功”,则不会向业务层回调“拉流重试事件”。

  3)修复“开始拉流后,使用相同的StreamID重复拉流,SDK内部会重新拉流的Bug”,修改后的逻辑为“保持之前的拉流状态”。

  开始一次推流后,如果没有向业务层通知过“推流成功“,则不会向业务层回调“推流重试事件”。

  2)修复“开始拉流后,使用相同的StreamID重复拉流,SDK内部会重新拉流的Bug”,修改后的逻辑为“保持之前的拉流状态”

  1)开始一次推流后,如果没有向业务层通知过“推流成功“,则不会向业务层回调“推流重试事件”。

  2)开始一次拉流后,如果没有向业务层通知过“拉流成功”,则不会向业务层回调“拉流重试事件”。

  3)修复“开始拉流后,使用相同的StreamID重复拉流,SDK内部会重新拉流的Bug”,修改后的逻辑为“保持之前的拉流状态。

  1)开始一次推流后,如果没有向业务层通知过“推流成功“,则不会向业务层回调“推流重试事件”。

  2)开始一次拉流后,如果没有向业务层通知过“拉流成功”,则不会向业务层回调“拉流重试事件”。

  2)修复“开始拉流后,使用相同的StreamID重复拉流,SDK内部会重新拉流的Bug”,修改后的逻辑为“保持之前的拉流状态”。

  1)开始一次推流后,如果没有向业务层通知过“推流成功“,则不会向业务层回调“推流重试事件”。

  2)开始一次拉流后,如果没有向业务层通知过“拉流成功”,则不会向业务层回调“拉流重试事件”。

  修复“开始拉流后,使用相同的StreamID重复拉流,SDK内部会重新拉流的Bug”,修改后的逻辑为“保持之前的拉流状态”。

  1)开始一次推流后,如果没有向业务层通知过“推流成功“,则不会向业务层回调“推流重试事件”。

  2)开始一次拉流后,如果没有向业务层通知过“拉流成功”,则不会向业务层回调“拉流重试事件”。

  1)增加接口,支持直播答题(version1.0.3)下发题目答题信息收集成绩下发

  • 本文来自: 老铁博客,转载请保留出处!欢迎发表您的评论
  • 相关标签:小程序直播  
  • 已有0位网友发表了一针见血的评论,你还等什么?

    必填

    选填

    记住我,下次回复时不用重新输入个人信息

    必填,不填不让过哦,嘻嘻。

    ◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。