关于音视频:QUIC技术创新-让视频和图片分发再提速

简介:在1月12日的「阿里云CDN产品发布会-新一代传输协定QUIC让CDN更快一步」之上,阿里云技术专家淮叶分享了QUIC技术及其利用落地实际,内容蕴含:QUIC协定介绍、相比TCP有哪些劣势、利用场景以及技术落地实际中的协定库抉择,QUIC协定软件实现、落地技术架构和性能优化。 随着互联网的疾速倒退,根底网络环境也在发生变化,WEB网络协议也经验了HTTP1.0、HTTP1.1、HTTP2.0以及行将迎来HTTP3.0; HTTP3.0将以QUIC协定代替TCP作为传输层,具备stream多路复用、握手0RTT、连贯迁徙以及用户态拥塞算法诸多劣势。CDN产品关注QUIC协定演进并实际落地,从gQUIC协定到规范IETF QUIC协定曾经部署在CDN边缘节点,并在短视频和图片业务场景实际有不错的收益。 在1月12日的「阿里云CDN产品发布会-新一代传输协定QUIC让CDN更快一步」之上,阿里云技术专家淮叶分享了QUIC技术及其利用落地实际。本文依据分享内容梳理,包含以下三个局部: QUIC协定介绍,包含协定诞生历史、根底个性、相比TCP有哪些劣势,以及QUIC协定能够利用在哪些业务场景CDN QUIC技术落地实际,包含协定库抉择,QUIC协定软件实现以及QUIC落地技术架构,以及QUIC性能优化,QUIC产品如何接入应用CDN QUIC技术落地场景,次要介绍阿里巴巴团体业务应用QUIC减速后的收益,以及背地的一些优化措施QUIC协定介绍当咱们拜访视频网站和APP利用时,常常会遇到各种各样的性能问题,网页加载慢、视频卡顿、网络出错,其中要害影响因素就是网络协议。 HTTP 协定作为互联网web协定,经验了几次重要的降级: HTTP1.0 -> HTTP1.1:反对长连贯,申请pipeline个性,通过缩小了TCP三次握手,升高连贯建设的开销HTTP -> HTTPS:减少TLS层握手,传输内容加解密,因减少平安个性,故减少建连提早HTTP1.1 -> HTTP2:H2个性是申请数据流的多路复用与头部压缩,进步了单连贯的并发能力从HTTP1.0降级到HTTP2,其中传输层协定没有变动都是基于TCP协定。TCP协定是牢靠传输协定,须要三次握手状态,还有队头阻塞问题,为了解决这些问题,基于UDP设计实现的一种牢靠传输协定——QUIC协定应运而生。因而,HTTP协定再次降级。 HTTP2->HTTP3:HTTP3基于QUIC协定,因而具备QUIC协定的传输个性,解决TCP队头阻塞问题,具备TLS1.30-RTT、H2多路复用能力,还具备连贯迁徙能力。QUIC协定已于2021年5月正式标准化,编号为RFC9000。 QUIC 协定解决了哪些问题1. 低连贯延时QUIC 基于 UDP,无需 TCP 连贯,最好状况下,QUIC 能够做到 0RTT 开启数据传输。而基于 TCP 的 HTTPS,即便在TLS1.3的early data下依然须要 1RTT 开启数据传输。然而对于常见的 TLS1.2 齐全握手的状况,则须要 3RTT 开启数据传输。 2. 无队头阻塞尽管 HTTP2 实现了多路复用,然而传输层仍然应用的是TCP,一旦呈现某个报文丢包,将会影响多路复用下的所有申请流。然而QUIC 基于 UDP,在设计上就解决了队头阻塞问题。同时HTTP3应用 QPACK 编码替换 HPACK 编码,在肯定水平上也加重了 HTTP 申请头的队头阻塞问题。 3. 用户态拥塞管制QUIC 的传输管制不再依赖内核的拥塞控制算法,而是实现在应用层上。这意味着能够依据不同的业务场景,实现配置不同的拥塞控制算法以及参数,甚至同一个业务的不同QUIC连贯也能够应用不同的拥塞控制算法。 4. 连贯迁徙当理论用户的网络发生变化时,从 WIFI 网络切换到 4G 网络时,用户地址发生变化,基于 TCP 的 HTTP 协定无奈放弃连贯的存活;而QUIC 基于连贯 CID 作为连贯标识, 依然能够保障连贯存活和数据失常收发。 QUIC协定与TCP协定比照既然QUIC协定设计初衷是解决传输层协定问题,与其竞对的就是TCP协定,那么从传输协定个性剖析两种协定设计差别,可得出以下比照: ...

January 18, 2022 · 1 min · jiezi

关于音视频:实时音视频入门学习开源工程WebRTC的技术原理和使用浅析

本文由ELab技术团队分享,原题“浅谈WebRTC技术原理与利用”,有订正和改变。 1、根本介绍WebRTC(全称 Web Real-Time Communication),即网页即时通信。 是一个反对网页浏览器进行实时语音对话或视频对话的技术计划。从前端技术开发的视角来看,是一组可调用的API规范。 在WebRTC公布之前,开发实时音视频交互利用的老本是十分低廉,须要思考的技术问题很多,如音视频的编解码问题,数据传输问题,延时、丢包、抖动、回音的解决和打消等,如果要兼容浏览器端的实时音视频通信,还须要额定装置插件。 2010年5月:Google以6820万美元收买VoIP软件开发商Global IP Solutions的GIPS引擎,并改为名为“WebRTC”(见《了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化》)。旨在建设一个互联网浏览器间的实时通信的平台,让 WebRTC技术成为 H5规范之一。 2012年1月:谷歌曾经把这款软件集成到Chrome浏览器中,Opera初步集成WebRTC。 2013年 6月:Mozilla Firefox[5]公布22.0版本正式集成及反对WebRTC。 2017年11月:W3C WebRTC 1.0 草案正式定稿。 2021年1月:WebRTC 被 W3C 和 IETF 公布为正式规范(见《WebRTC 1.0: Real-Time Communication Between Browsers》)。 (本文已同步公布于:http://www.52im.net/thread-38...) 2、重要意义WebRTC的呈现、倒退和被业内规范组织(如W3C)等广泛认可,对于当下和将来大前端技术倒退具备重要的意义。 升高在web端的音视频交互开发门槛: 1)以往的音视频交互开发对于Web开发者而言具备肯定技术门槛;2)当初借助于WebRTC,Web开发者通过调用JS接口,可疾速的实现音视频交互利用。 防止依赖、插件造成的次生问题: 1)以往的音视频交互利用构建依赖于各种插件、软件和服务器等;2)当初借助于支流浏览器即可造成端到端的音视频交互。 统一化和标准化对传统音视频交互环境差异性的躲避: 1)以往音视频交互须要面对不同的 NAT 、防火墙对媒体 P2P 的建设带来了很大的挑战;2)当初WebRTC 中有P2P 打洞的开源我的项目 libjingle ,反对 STUN,TURN 等协定。 更高效优化的算法、技术对于音视频交互性能的晋升: 1)WebRTC 通过NACK、FEC技术,防止了通过服务端路由直达,缩小了提早和带宽耗费;2)还有 TCC + SVC + PACER + JitterBuffer 等技术对于音视频流畅性进行了优化。 3、技术特色WebRTC内容丰盛,次要的技术特色蕴含以下几点。 1)实时通信: WebRTC是一项实时通信技术,容许网络应用或者站点,在不借助两头媒介的状况下,建设浏览器之间点对点(Peer-to-Peer)的连贯,实现视频流和(或)音频流或者其余任意数据的传输。 2)无依赖/插件: WebRTC蕴含的这些规范使用户在无需装置任何插件或者第三方的软件的状况下,创立点对点(Peer-to-Peer)的数据分享和电话会议成为可能。 3)协定栈 泛滥: WebRTC并不是繁多的协定,蕴含了媒体、加密、传输层等在内的多个协定规范以及一套基于 JavaScript的 API,它包含了音视频的采集、编解码、网络传输、显示等性能。通过简略易用的 JavaScript API ,在不装置任何插件的状况下,让浏览器领有了 P2P音视频和数据分享的能力。 ...

January 10, 2022 · 3 min · jiezi

关于音视频:阿里云低代码音视频工厂正式上线为企业用户提供音视频开发最短路径

简介:阿里云低代码音视频工厂正式上线,极大水平升高音视频开发门槛,突破传统音视频开发壁垒,全新定义音视频利用开发。 1月5日,阿里云低代码音视频工厂正式上线,极大水平升高音视频开发门槛,突破传统音视频开发壁垒,全新定义音视频利用开发。 低代码音视频工厂基于云原生、音视频和AI智能算法等先进技术,可提供易接入、强扩大、高效部署和笼罩多场景的音视频服务。最快通过三步集成,十行代码,即可帮忙企业客户搭建高品质的专属音视频业务平台。 阿里云视频云产品负责人董陈强示意:随着技术的倒退,音视频未然成为一项根底能力,渗透到各个行业、各个场景,而基于音视频业务的第二增长空间成为泛滥行业和企业着力摸索的方向,低代码音视频工厂恰好提供最短、最快、最轻的技术实现门路,助力企业低门槛、低成本地极速搭建高牢靠、多场景、全能力、定制化的音视频产品及服务,从而彻底突破了行业对音视频开发的繁冗零碎和技术壁垒,真正为客户打造了音视频利用开发的最短门路,助力客户新商业模式的疾速验证与迭代。 低代码音视频工厂可能突破传统音视频开发所沉积的事实壁垒,源于产品底层视频原生利用开发平台,作为底座,其让低代码音视频工厂能够延展出更多元的场景和能力。产品的技术负责人曾形容,这是一个云原生的、围绕多重体验技术构建的、具备残缺的开发生态利用开发平台,具备云端一体、极致弹性,领有多端统一的体验性。阿里云视频云基于如此弱小的开发平台底座,将为客户的音视频利用开发,提供更低的接入门槛、更易拓展的能力、更高的灵便度、更多的新场景拓展,从而实现更低的老本,以助力客户构建自有的音视频业务平台。 纵观近年,基于数字化趋势下的音视频数智化在一直普适,云、AI、音视频所联合而生的视频云已逐渐倒退成大视频行业的底座,IDC预测,中国视频云市场到2025年将达到2000亿元人民币,其中除了大视频产业的迅速倒退以外,更多非视频的行业和企业在一直退出赛道,尝试构建本人的音视频能力,而低代码音视频工厂正为此而生,并在发明更多新的可能。 原文链接本文为阿里云原创内容,未经容许不得转载。

January 7, 2022 · 1 min · jiezi

关于音视频:视频通信中的码率控制算法

码率控制技术RC(Rate Control)是视频编码中一个十分重要的技术模块。不同的利用场景对视频编码的码率管制有不同的需要,离线编码通常采纳可变码率(VBR),实时视频零碎通常采纳恒定码率(CBR)。本篇技术干货将深度分析视频编码中的码率控制算法,剖析其背地的数学模型及实践,心愿能帮忙大家更好地了解视频通信中的码率控制算法。 PART 01 码率管制类型码率管制次要指编码过程中,通过调整QP来管制视频码率的行为。在不同的应用场景下,用户对视频的码率大小、稳定性会有不同的要求,因而码率管制的类型也多种多样。比方观看离线视频文件时,往往不须要此视频具备恒定的码率,因为整个文件都在本地,只有磁盘IO和设施解码能力都合格,根本就不会产生卡顿问题(这里不探讨硬件解码的buffer限度以及内网NAS的带宽限度)。所以压抑这类视频时会偏向于保证质量而非码率平稳性。画面纹理比较复杂或静止激烈的场景,码率给高一些,以保障画面质量;而画面简略的场景,码率就给低一些,节俭硬盘空间。这种码率控制策略咱们统称为可变码率(VBR)。但在观看在线视频时,因为用户带宽是恒定的,可能缓存的数据量也无限,所以须要对码率做一些限度。否则一些刹时码率过高的片段可能会引起卡顿。此外还有一点,因为CDN是按流量计费的,视频网站如果应用VBR编码视频会使带宽老本变得不可控。所以压抑这类视频时,会偏向于抉择恒定码率(CBR)。 不同场景下的码率管制需要本文接下来的探讨内容次要集中在CBR,但其中的一些改进算法其实也能够用在VBR。 PART 02 码率管制根基:RQ模型首先看一下码率管制的大体流程: 码率管制根本流程 能够看到整个流程都是围绕着RQ模型进行。这里的RQ模型指的是码率与QP的推导关系,能够说是码率控制算法的根基。它经验过屡次改良,精度也在一直进步,这里举几个例子: 一阶模型: 最简略的模型,在x264、OpenH264等编码器中被宽泛应用。式中Q指Q-step,即量化步长。R指Rate,示意码率。Comp示意图像复杂度,个别能够应用MAD(Mean Absolute Difference)来计算。是一个系数,须要咱们在编码过程中一直依据理论输入码率来更新。 二阶模型: 一阶模型的进阶版,JM中有应用。 R-模型: 在HM(HEVC Test Model)中被引入的模型[1],显著晋升了码率控制精度。式中的是率失真优化中应用的拉格朗日乘子,放在下节作为拓展内容介绍。而f()则是通过试验拟合失去的。比方HM中就是: PART 03 MAD值的获取与模型的更新下面提到图像复杂度能够应用MAD来计算,然而以后帧的MAD值只能在编码后能力失去。这与QP须要在编码前确定这一点相矛盾。另外,在模型确定后,咱们还须要确定模型的更新形式及速率。通过进步模型系数的更新速率,能够使编码器的输入码率更加安稳;但绝对的,画面质量可能因为QP变动幅度过大而降落。针对这些问题,不同的编码器抉择了不同的计划: 在JM中,应用了一个一阶线性模型依据过来帧的MAD来预测以后帧的对应值。而RQ模型的系数则间接通过以后帧的编码后果来反向计算失去。 在OpenH264和x264中,则放弃了MAD的计算,转而合并了 ,把它作为一个整体来计算。 对于R-模型,其提出者也曾经设计了对应的更新公式和经验值供咱们参考[1]。 模型更新这部分内容,更多是工程实际上的考量,须要依据教训和测试状况一直调整。 拓展:是什么R-模型中的是率失真优化中的一个系数。这里的率失真优化,指的是编码过程中的一个优化步骤。要具体解释它,咱们须要先理解率失真实践。它起源于香农的钻研[2],大抵能够概括为:在给定的信源散布以及可承受的失真度D下,求信息数据量R的实践最小值。显然,可承受的D越大,其对应的R也就越小。这个R-D的关系边界,咱们称为率失真曲线,即下图中的红线[3]。旁边的绿线则是编码器理论工作区域的边界,它和理论值存在肯定差距。 R-D曲线视频编码标准提供了大量的工具集,或者说编码模式,它们就相当于上图的绿点。在它们之中抉择一个失当的来应用是一件比较复杂的事件。留神到这个问题实质是一个数学最优化问题,所以能够利用拉格朗日乘数法的离散模式来解决它。简略地说,引入一个拉格朗日乘子,构建代价函数,再去求取代价函数的最小值即可: 艰深地了解,就相当于失真与码率的权值。给定了,也就给定了一个断定模式好坏的规范。如下图所示,求代价函数最小值,相当于求斜率为的直线与R-D曲线的切点。在编码过程中,不论是模式抉择,还是静止矢量的比拟,都会利用到这个办法。 拉格朗日乘子R-D曲线斜率R-模型的提出者首先依据试验数据提出R-D曲线能够近似拟合为一条双曲线,再依据是R-D曲线斜率这一点,求得了R-模型: PART 04 码率管制优化算法上文介绍的内容,属于码率管制外围算法,其目标仅为管制输入码率,使其尽可能地靠近指标。但在理论利用中,咱们并不需要这么严格地执行。在输入码率根本满足要求的前提下,咱们仍然有肯定的调整空间来改善画面质量。下文将介绍几种这方面的算法。 Adaptive-Quantization因为人眼对不同类型的画面的细节感知水平是不同的,所以给不同画面内容给予雷同的权重来调配码率实际上是比拟节约的。比方高速静止的物体就能够绝对动态物体含糊一点。在这方面做文章的算法个别归类为基于感知的码率控制算法。而其中一类比较简单且应用宽泛的算法,叫做Adaptive Quantization(AQ)。简略来说,它利用图像的方差或其余相似特色来掂量以后宏块的复杂度,对于内容较简单的宏块,算法认为能够适当舍弃其细节,所以增大其QP;而简略的宏块则反之。通过这种调整,视频的主观品质能失去大幅晋升。现在很多编码器都实现了AQ,比方x264的实现如下所示。计算失去的qp_adj即QP偏移量,会叠加到R-Q模型计算出来的QP上: // x264的AQ外围实现。ac_energy_mb计算宏块像素值方差。strength代表AQ强度,由用户配置。uint32_t energy = ac_energy_mb( h, mb_x, mb_y, frame );qp_adj = strength (x264_log2( X264_MAX(energy, 1) ) - (14.427f + 2(BIT_DEPTH-8)));利用人眼感知能力的码率控制算法还有很多,比方基于最小可发觉误差(JND, Just Noticeable Distortion)的,或者基于机器学习的,这里不再开展。值得一提的是,因为是针对主观视觉体验的优化算法,通过PSNR等主观伎俩测试往往无奈体现这些算法的劣势。 ...

December 21, 2021 · 1 min · jiezi

关于音视频:帮你积累音视频知识Agora-开发者漫游指南正式启航

“运气是设计的残留物。”——John Milton如果玩过《全面战争:中世纪 II》,或者读过 John Milton 书的人,可能对这句话有印象。咱们发现,很多小伙伴从疫情期间开始理解音视频行业,尽管对音视频很感兴趣,看了很多相干公众号和文章,还是没能胜利入门。可能是因为内容零散不成体系,可能是因为没有上手实际,也可能是因为没工夫没人督促慢慢就忙了、忘了、放弃了。 正如 John Milton 所说,系统性学习一个新的门类,除了有高质量的结构化常识之外,也须要有“导师”及“搭档”的疏导及陪伴,能力让趣味的能源成为生产力,从而成为学习路上的“幸运儿”。「Agora 开发者漫游指南(Agora Hitchhiker's Guide to the Community)」为此而生! 什么是「Agora 开发者漫游指南 Agora Hitchhiker's Guide to the Community」?「Agora 开发者漫游指南(Agora Hitchhiker's Guide to the Community)」邀请酷爱前端开发、关怀音视频畛域倒退、心愿进入音视频行业、乐于和大家一起交换成长的小伙伴,通过「Agora 开发者漫游指南(Agora Hitchhiker's Guide to the Community)」与社区独特成长,帮忙更多的开发者在实时音视频畛域获得提高。 如何报名退出「Agora 开发者漫游指南」不收取任何费用,也没有任何业务/技能方面的硬性要求。胜利提交申请即视为退出「Agora 开发者漫游指南」。 点击『浏览原文』立刻填写报名表单扫描下方二维码立刻填写报名表单 ⛰️ 漫游地图申请后即可退出开发者漫游指南,每期 1 个月。在这一个月里,咱们每周都为大家筹备了不同的技术内容、Demo、入手指引。你能够随时退出,随时开启这次漫游~ 在旅程最初,还会有一场“小试炼”等着你,实现它,你就能失去限定的处分! 第一周——音视频行业 & Agora 基础知识简介及科普 第二周——跑通 demo,开始上手 第三周——进阶细分畛域教程及入手指引 第周围——入手试验,及 final test! (实现周围学习并通过 final test 的小伙伴,将收费享受一年的 声网MVP 权利哦!) 咱们为大家筹备了什么漫游银河系必不可少的是毛巾,咱们给社区的漫游者筹备的则是 Special package! 有体系的音视频行业从 0 到 1 成长/学习门路有人陪伴、有人督促的良好学习气氛与声网 MVP 大牛、社群沉闷成员的近距离交换机会通过社区的徽章机制,兑换取得社区周边、技术书籍、技术大会门票等礼品还有长期技术沟通和反对、社群福利和流动、声网招聘绿色内推通道等福利哦... ...

December 16, 2021 · 1 min · jiezi

关于音视频:视频特辑数据分析师必备快速制作一张强大好用的大宽表

简介:随着企业数字化过程的逐步推进,在日常经营过程当中会积淀下越来越多的数据信息。 每当想做数据分析的时候,就会发现想要的指标扩散在不同的数据源、数据集、数据表当中。 Quick BI的数据关联性能,能够帮忙数据分析师疾速将指标进行汇聚,造成一张弱小好用的大宽表。 一起来看看Quick BI是如何做到的吧! 随着企业数字化过程的逐步推进,在日常经营过程当中会积淀下越来越多的数据信息。 每当想做数据分析的时候,就会发现想要的指标扩散在不同的数据源、数据集、数据表当中。 Quick BI的数据关联性能,能够帮忙数据分析师疾速将指标进行汇聚,造成一张弱小好用的大宽表。 一起来看看Quick BI是如何做到的吧! 数据集关联建模您须要通过不同报表中都具备的雷同字段来进行关联。如「demo_订单信息明细表」和「demo_渠道信息维度表」中都蕴含独特字段「渠道ID」,抉择「渠道ID」来进行数据关联,就能够获取蕴含订单信息和渠道信息的残缺表单。不便后续剖析数据。 将指标表单拖入编辑区在自动弹出的设置界面抉择关联字段和关联模式点击确定并保留数据集 不同关联模式的区别◼左外连贯(left join):以左表为基准,查问后果中蕴含左表全副数据,右表匹配数据不存在时用null代替; ◼右外连贯(right join):以右表为基准,查问后果中蕴含右表全副数据,左表匹配数据不存在时用null代替; ◼内连贯(inner join):通过id将左表和右表连接起来产生一个新表,新表是由这个表的交加局部组成; ◼全连贯(full join):左连贯和右连贯的一个合集,蕴含左表和右表的全副数据,匹配不上的显示为null。 维度值二次分组分组维度用于将维度值分组的场景,例如对年龄字段分组,分为未成年、青年、中年、老年这几个大区,别离查看每个年龄段人员的疫苗接种状况。 在数据预览区域,单击新建分组维度在新建分组字段对话框,依照以下步骤配置后,单击确定。(反对利用在天文分组、年龄分组、日期分组等场景) 阿里云数据中台是阿里巴巴数据中台惟一商业化输入,以数据中台方法论为内核,构建起”快、准、全、统、通“的智能大数据体系。 阿里云数据中台产品矩阵是以Dataphin为基座,以Quick系列为业务场景化切入: Dataphin,智能数据建设与治理Quick BI,数据可视化剖析Quick Audience,一站式消费者经营和治理Quick Tracking,全域行为洞察Quick Stock, 智能货品经营Quick Decision,风控决策数字引擎目前正对外输入系列解决方案,包含通用数据中台解决方案、批发数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案等。 原文链接本文为阿里云原创内容,未经容许不得转载。

December 16, 2021 · 1 min · jiezi

关于音视频:网易云信发布两大元宇宙解决方案打响进军元宇宙第一枪

12 月 4 日,由网易智企主办的 2021 网易翻新企业大会在杭州隆重举行。大会以“科技将来说,商业相对论”为主题,网易(杭州)副总裁、网易智企总经理阮良在会上公布网易云信两大元宇宙解决方案——「IM + RTC + 虚拟人」解决方案和「游戏 / VR 语音」解决方案(文末能够收费试用),引发线上线下观众宽泛关注。 阮良示意,在通信技术倒退过程中,元宇宙就是社交网络从2.0向3.0的逾越,将来会逐渐进入到下一代互联网,形成全域互联网场景利用。3.0 时代最大的特点是立体化、沉迷式,将来将是一个基于事实的大型 3D在线世界。网易云信心愿依靠网易 20 余年的技术积攒和根植于心的“娱乐社交”基因,率领大家正式开启元宇宙的大门,迈入 3.0 时代。 向下一个 10 年迈进,向互联网 3.0 阶段进发10 年一个阶段。 2000年至 2010 年,互联网 1.0 阶段,PC是次要承载工具;2010 年至 2020 年,互联网 2.0 阶段,智能手机成为支流;当初是 2021 年,正是下一阶段的终点,3.0 会是什么样?其实,答案曾经逐步清晰,并出现在咱们眼前,那就是元宇宙。 (流动现场 PPT) 2021 年,元宇宙的火爆超出设想,泛滥企业纷纷布局。 显然,元宇宙的这股风曾经刮起来了,而且和互联网 1.0、2.0 期间的现象齐全不同,元宇宙并不局限于科技圈、互联网圈,而是从一开始,上下游产业链以及不同行业就曾经充沛退出进来。 元宇宙真的那么香吗? 艰深的解释,元宇宙是一个平行于物理世界的虚拟世界,除了吃饭、睡觉等生存必须,其它都能够在虚拟世界失去满足。看过电影《头等玩家》的观众想必更有感触,工作、生存、学习、恋爱……那是一个无所不能的世界,一个令人向往的世界,如果真的有那样一个世界,两个字形容,“真香”。 互联网 1.0 和 2.0 期间,网易在娱乐社交畛域始终走在行业前列。凭借来自网易的“娱乐社交”基因,脱胎于网易 C 端业务、并几经外部产品验证的网易云信对于该行业也有粗浅的了解和洞察,先后陆续公布大型直播流动、多人语音聊天室、PK 连麦、一体化实时独唱等场景化解决方案。 作为娱乐社交行业的引领者,网易云信曾经携手客户进行诸多翻新与摸索。例如,为 TFBOYS 七周年线上演唱会提供技术支持,助力网易云音乐“一起听”性能为用户打造晦涩、稳固的听歌、互动体验,为配音秀实现多达 12 人的实时在线聊天(一般语聊房的同时在线人数个别为 8 人左右)等等。 当初,互联网 3.0 时代行将到来,网易云信竞争力仍旧。 网易云信公布两大元宇宙解决方案,继续引领娱乐社交行业元宇宙是一个巨大的命题,互联网 3.0 是一个远超 2.0 领域的概念。因而,元宇宙的实现难度远比挪动互联网更高,须要解决的技术难题更多。这其中有几个外围问题要解决,就像物理世界须要很多根底元素一样,元宇宙也须要。 ...

December 8, 2021 · 1 min · jiezi

关于音视频:声网-X-远程超声实时音视频解决基层看病难-推动医疗资源均衡化

实时互联网像触角一样,通过情景的共享延长开来,链接着咱们彼此的线下、线上生存,造成一张不可分割的网络。随着社交直播、在线教育、视频会议成为公众生存不可或缺的一部分的同时,智能手表、智能作业灯、视频双录、视频核保、近程问诊等更多新场景也在一直锋芒毕露。 在咱们看来,摸索实时互联网将来场景的过程,就如同是“洞见微光”的过程。声网因而推出【捕“光”之旅】系列策动,心愿可能从场景、业务与技术联合的角度分享实时互动新场景,看看他们是如何“洞见”并“抓住”这实时互联网的将来之光。 “名医下基层”始终被视为解决医疗资源不均衡的良方之一,然而名医来一次远不能一劳永逸,名医始终来又不事实。然而实时音视频就能够让名医高频率下基层,近程解决医疗资源不均衡。 近年来,随同国家大力发展数字化医疗,一些须要借助医疗设施能力实现的视频问诊场景,如“近程超声”、“手术示教”、“近程操作培训”等也在走进基层医院,推动优质医疗资源的下沉。【捕“光”之旅】第七期文章,咱们来聊聊在医疗行业,借助实时音视频技术如何实现近程超声查看,解决基层“看病难”的难题。 从2020年11月开始,在甘肃省某县城,全县的镇卫生院、社区医院与县医院都陆续上线了近程实时超声查看零碎,为基层社区、偏僻山区的患者提供了近程查看服务,特地是在今年年初夏季山区下雪封路后,基层患者无奈出山返回县城看病,近程超声查看零碎更为多个急症患者及时提供了超声检查和医治意见。这样的医疗场景在河北、新疆等全国多个县城的基层医院中也在同步落地,而这背地来自广州铱度的近程会诊零碎以及声网的实时音视频技术正在施展重要作用。 广州铱度是一家专一于医联体建设及为各医疗机构提供近程医疗信息化服务解决方案的公司,在近程超声的场景中,县医院的超声科医生通过“铱度”的近程会诊零碎连线百公里外的基层卫生院的医师,对多名患者进行一场线上“面对面”的超声会诊,整个会诊过程,借助声网的实时音视频技术,近程会诊零碎能够实现高清医疗超声影像的实时传输,医生再依据实时的超声图像对患者进行实时诊断,诊断过程能够做到超低延时、高晦涩。 来自“铱度”的数据显示,在甘肃某县城,近程超声查看零碎每月诊断的患者数量已从上线之初的每月5-10例,倒退到目前每月50-80例,所有基层卫生院的医师曾经疾速把握了零碎应用,在县医院的鼎力配合下,近程超声查看已成为基层近程医疗的常态服务。 图:甘肃某县的医生通过近程超声系统对患者进行实时诊断 声网Agora 医疗金融行业产品总监聂正学示意,相比于一般的视频问诊,近程超声查看对近程会诊零碎、实时影像传输、实时音视频互动提出了更高的要求。例如“铱度”的近程会诊零碎须要蕴含近程超声软件、近程影像等性能,并与电子病历深度交融,对于声网而言,在实时超声影像传输、实时诊断的过程中也会面临保障超声影像的高画质、基层医院网络环境简单等一系列技术难点,目前声网为“铱度”等平台提供的近程超声技术解决方案在行业领有五大外围劣势: 1. 提供多流实时传输:超声实时影像+视频流+音频流 在近程实时超声查看的在线模式中,声网提供了超声实时影像+视频流+音频流的三路流实时同步传输,反对医生实时扫查+实时超声影像两路视频同步出现,无效的保障了县医院医生在实时察看超声动静影像、超声扫查手法和体位的同时还能同步领导基层医生正确操作超声设施,进行实时音视频交换,达到最佳的近程扫查成果。 2. 反对动静+动态影像采集,实时录制+回放 在医生实时察看超声影像的过程中,常常会针对某个部位的影像进行实时采集,以供实时诊断以及前期的专家剖析。在声网的助力下,铱度的近程实时超声查看零碎能够反对动静+动态的影像采集,满足医生多样化的诊疗需要。同时,声网还领有业内当先的实时录制性能,可实现超声查看中实时超声影像、实时音视频诊断过程的录制,帮忙医生通过回放对超声查看过程进行二次剖析与学习。 3. 高清超声影像实时传输,提供对超声截图的标注 在近程超声查看过程中,超声影像的清晰度将十分影响医生对影像后果的诊断,而声网能够做到高清超声影像的实时传输,最高可反对1080P 60fps的高清画质。同时,声网的解决方案还反对医生在接管到患者的超声影像后,能够对有疑难的影像部位进行实时标注,并提供对超声截图的图像增强、无损放大性能。 4. 反对跨国会诊,抗弱网传输 在声网实时互动技术的撑持下,近程超声查看也能够实现跨国会诊,引入国外的医疗专家资源,声网自建的 SD-RTN™ 软件定义实时网笼罩寰球 200+ 国家和地区,可做到寰球端到端优质传输率>99%,寰球端到端网络延时小于400ms,延时中位数76ms,无效保障跨国会诊中医生与患者音视频互动的超低延时体验。 同时在近程超声落地基层医院的过程中会广泛面临偏僻山区卫生院简单的网络状况,针对弱网状况下的音视频互动,声网领有一套抗弱网传输与抗丢包算法,联合网络探测(如延时预计、带宽预计、丢包预计等)、抗丢包技术(如ARQ、FEC等)、自适应jitter buffer、网络拥塞控制策略等,可实现70% 丢包下视频通话晦涩、80% 丢包下语音通话晦涩。 5. XLA体验品质保障 在为客户提供稳固、牢靠实时互动技术的同时,声网还提供业内独有的XLA体验品质保障。 2020年7月,声网设计定义并推出了实时互动行业首个体验质量标准-XLA。辨别于SLA,XLA 不仅关怀实时互动的可用性和服务质量,还关注用户的体验品质,是首个围绕用户理论体验建设的可量化、可查证、可赔付的体验质量标准和保障。声网XLA致力于提供优质实时互动体验质量保证,通过体验品质的标准化来推动实时互动从“可用”走向“好用”,让“好用”成为“规范”。 通过XLA,客户能够收费取得声网对登陆成功率、端到端延时、音视频卡顿率等多个维度的实时互动体验品质承诺和保障,不达标就会被动赔付,不再须要去放心终端用户的体验品质问题,真正做到用的释怀,用的满意! 来自“铱度”的相干技术负责人示意:“在声网技术的大力支持下,近程超声查看零碎基于一般光纤宽带(100M带宽)下的低延时视讯通话与超声影像高保真传输,可能很好的满足农村地区的近程医疗需要,让咱们防止了大量硬件投资。同时医生对基于B/S架构(即浏览器/服务器模式)的浏览器形式,能很快适应。对灵便的多路音视频与医疗业余影像的综合传输,感到不便,能疾速解决他们的业余沟通需要。” 聂正学也示意,实时互动的技术价值不止于帮忙开发者疾速构建稳固、晦涩的线上互动场景,在医疗、金融、政务畛域也在一直施展社会价值。例如近程超声、手术示教等场景,更能够让优质专家资源无效下沉到基层医院,解决医疗资源均衡化的难题,同时也通过近程会诊,晋升基层医生的检查和诊断能力,更不便了农村患者的及时就医医治。此外,在与老百姓民生非亲非故的医保场景,在实时互动技术的撑持下各地的医保局陆续上线了医保零碎视频近程服务平台,老百姓只需通过 App 或者小程序向工作人员发动视频通话,并通过人脸识别技术就能疾速办理医保。 将来随同国家大力发展数字化经济,RTE实时互动在生存数字化、基层治理数字化方面将一直奉献更多的社会价值。

December 6, 2021 · 1 min · jiezi

关于音视频:优酷播放黑科技-自由视角技术体验优化实践

作者:邓小龙(白展) 本文为《优酷播放黑科技》系列文章第一篇《自在视角技术体验优化实际》,之后咱们会陆续上线《基于WebRTC实现的直播"云多视角"技术解析》《自在视角技术的全链路策略与落地实际》,欢送点击左上角【阿里巴巴挪动技术】关注咱们,点关注不迷路 ~《这!就是街舞》第四季大家看了吗?不晓得有没有小伙伴跟笔者一样,“DNA”都要跟着舞动了起来。除了炸裂的舞台,堪比跨次元的实在观影体验,让用户在自在视角视频体验成果下身临其境。 自在视角视频作为优酷内一种新鲜的观看模式,给用户带来了全新的观影体验,在对外的泛滥单干中作为优酷的亮点内容也引起了较高的关注度。然而随着产品声量的不断扩大,以后自在视角在整体的播放体验及投放链路上还有很多诸如,播放不晦涩、内容不清晰、设施笼罩较低等问题须要优化解决。 基于此,优酷技术团队在上半年对自在视角进行了一次全面的优化降级。接下来的内容,咱们将从全面优化降级的整体指标,围绕播放体验及用户规模开展,详解优酷播放器团队的整体优化策略及计划。 自在视角是什么图1 上图1是自在视角视频每帧画面的款式,以下对立叫深度图。 自在视角原理:自在视角视频是在原有播放链路的根底上,新增自在视角算法SDK对每帧深度图进行解决,生成指定角度的画面最终展现给用户。 客户端架构设计 这部分次要会介绍自在视角实现的外围逻辑。两头由两个虚线框隔开的两个模块右边是自在视角在播放器SDK中实现的逻辑,左边是针对自在视角播放体验优化的策略,优化策略在前面会做具体的介绍。 播放业务层: 用户外围交互包含角度旋转齿轮(次要生成角度信息供算方侧应用)、自在视角视频用户提醒、转场动画;通过开关管制做到线上性能可随时关上或敞开。播放器中间层: 次要包含两局部,一是中间层链路革新反对自在视角,二是下载自在视角视频所须要的算法文件,下载结束当前将文件门路传给算法层应用。 播放器内核层:解决内核与算法层之间的数据交互,而后将算法SDK解决好的纹理数据合成当前间接上屏展现。 下载器:负责优酷点播和直播视频文件的下载,不必针对自在视角做特地的革新,次要是应用到了下载器的多分片下载性能晋升下载效率。 算法: 这层次要的职责是基于算法将深度图重建生成指定角度的画面。 自在视角性能优化计划优化方向: 首先咱们得搞清楚为什么卡顿能力晓得如何去优化。经调研,卡顿起因是因为播放器以后数据有余所导致的,播放器须要期待足够的数据当前能力持续播放,所以咱们得出结论,提前下载数据、多通道下载、升高视频的码率从这三个方面动手就能够升高卡顿率;计划尝试: 后期咱们尝试了预缓存、视频流智能档、内核动静Buffer、多通道下载、自在视角动静降角度、播放器双实例切换降码率、连播预加载、过狂飙模式、视频AV1编码降码率共9种计划。在通过理论可行性调研后,最终确定预缓存、视频流智能档、内核动静Buffer、多通道下载这4种计划。优化实际卡顿率优化视频流智能档 上图是智能成果示意图,智能档是依据智能档算法动静去决定下一个TS分片的码率,从而达到动静降低码率的成果。 智能档算法架构图 须要着重介绍的有这么几个点: 智能档控制器与数据源及其他模块的交互和管制: 收集视频元数据和播放状态信息(比方缓冲区时长buffer)、网络信息,分片级别的码率/清晰度抉择,清晰度切换管制,还有其它数据源链路上的事件响应和超时管制等;策略引擎框架: 反对多种策略实现运行的一个接口/环境/容器,每种算法策略实现依据从播放器内核和网络环境信息等输出,给定一个清晰度抉择的输入;数据链路闭环: 客户端决策信息埋点上报,云端数据分析解决,优化后的配置更新或模型下发。其中,策略框架及各种清晰度抉择的算法策略实现是整个智能档的外围灵魂,策略框架提供了一个平台,目前,优酷的智能档应用 ABTest 的形式反对了从基于各项离散规定到基于强化学习神经网络模型的多种算法策略的实现,这些算法能够依据配置或模型下发动静调整算法参数,相互比照优化,相互补充。内核动静Buffer通过策略配置平台对立下发指定策略动静设置内核buffer大小,以达到最大限度利用下载资源的目标。 多通道下载 如上图所示,多通道下载技术通过将每个独立的文件拆分成N个小块进行下载,每个小块对应右图一个下载通道,这样就能够通过多个通道并行下载,进步下载效率以达到升高卡顿的指标。 预缓存实现可缓存播控信息和视频流文件;(如下图2所示)反对策略动静下发视频预缓存大小;(如下图2所示)自在视角能力大一统:将自在视角能力的配置对立收到播控后盾,去掉客户端自在视角能力配置项,这样防止当前播控后盾和客户端配置不统一导致产生不可预测的问题。(如下图3所示)图2 图3 场景覆盖度因为自在视角算法SDK反对两种渲染模式,基于DIBR的一般模式,以及敞开DIBR的切相机降级模式。在这个条件的根底上,对于性能有余能够良好反对DIBR的设施,通过降级模式进入自在视角,这在技术和产品角度都是可行的。 革新前 革新后 数据比照&成果业务&技术优化成果: 街舞4自在视角视频(一个月)相较于去年同期街舞3点播总播放量晋升近2倍。晦涩度晋升近70%。 场景笼罩收益: 并不是所有的低端机型都能够反对自在视角的降级模式,因为场景非凡,算法要求的视频输出源的清晰度须要不低于4K,因而处于【4k解码, 反对DIBR】区间的设施才属于本次优化预期晋升的范畴;通过这次新增的降级渲染技术改造,新增笼罩近3成低端机型,最终总覆盖度从原来5成(仅反对中高端机型)晋升至近8成;总结为用户提供更优质、更丰盛的观影体验始终是咱们优酷秉持的指标,也是咱们继续一直摸索和尝试的能源。如何让用户感触到技术的温度,而不是仅仅看到的是寒冷的字面和数字上的晋升,让更优质的体验是用户切身能感触到的,这是咱们将来的致力的一个方向。同时咱们也在打造直播自在视角,竭尽所能的去摸索更多更新的观影形式。 下周,咱们会公布本系列《基于WebRTC实现的直播"云多视角"技术解析》,感激关注【阿里巴巴挪动技术】,咱们下篇持续聊。 关注【阿里巴巴挪动技术】官网微信公众号,每周 3 篇挪动技术实际&干货给你思考!

December 3, 2021 · 1 min · jiezi

关于音视频:开发者实践丨Agora-Home-AI-音视频的未来

本文作者是本届 RTE 2021 翻新编程挑战赛获奖者,来自上海交通大学的李新春。他分享了本次参赛作品的构思、零碎设计和开发的心得。 01 不得疏忽的背景从国家层面上讲,十四五期间我国人工智能倒退的方向之一是:基于 AI 硬件的新产品设计及平台将成为支流。以后,人工智能解决方案正由“软件”模式转变为“软件+硬件”模式。随着智能计算芯片与零碎、新型多元智能传感器件与集成平台等新一代人工智能根底撑持平台日渐成熟。以 AI 硬件为根底,在“端+云+芯片”协同倒退的背景下,产品的感知、了解、推理和决策能力将实现冲破。 从企业倒退来说,AI 技术正越来越多的利用的社会的各个方面,从根底的人脸识别到无人驾驶,无论是机器学习还是深度学习尽管是弱人工智能时代,但曾经足够让人们的生存产生显著的影响。因此,依靠企业应用实际,联合人工智能的倒退方向,打造出独具特色的人工智能产品是值得摸索策略方向。 02 本我的项目缘起因自己始终从事技术畛域相干工作,从 AR、VR 到当初的 AI。在一直的工作实际中积攒教训,也在一直思考将来技术如何扭转生存,所谓人工智能,在现阶段的利用次要的几个方面如工厂生产、生存服务、社会治理等等,各个领域相互独立,有本人独特的算法和模型,那是不是能够做一套云平台,接入各种音视频进行实时剖析并反馈,造成一套 AI 云服务平台?因而,本次参赛的出发点就是造成一套可行的利用实际,并提出一种云上 AI 平台的零碎架构。 03 零碎形成在本次我的项目中采纳了 YOLO V3 作为根底算法辨认引擎,采纳声网Agora 的音视频传输作为智能终端的数据起源,采纳开源硬件 NodeMcu 及其配套作为智能硬件终端代表,最终造成在家庭局域网内的智能家居平台。 YOLO V3:是 YOLO(You Only Look Once)系列指标检测算法中的第三版。在这一版本中晋升了对小指标的辨认性能,同时速度失去更好的晋升。目前该算法曾经更新到 V5 版本,在速度和辨认后果上有大幅晋升。简略的说,该算法可能达到实时得辨认数据,辨认精度也满足根本要求,同时在配置、应用和学习上老本较低。 Agora SDKs:在本我的项目中应用到声网提供的两款 SDK,RTC 实时音视频通信次要性能是进行实时视音频的传输,RTM云信令提供高效、高并发的实时音讯,这两款 SDK 兼容 iOS、Android、Windows、macOS、Web、小程序等 20 多个开发平台,能够不便的进行拓展和多平台交互开发。同时对于注册用户,每个月均有 10000 分钟的收费时长,这对于一般开发者齐全能够满足日常需要,并且实测在 4G 网络的状况下端到端提早<400ms,开发测试也是非常良好的体验。 智能硬件:我的项目中实际上利用包含智能小车管制的 Node MCU 和音视频传输的终端(树莓派Android things等)因为手头的终端性能太差,故开发采纳旧手机作为智能硬件管制终端,通过局域网对家庭内的所有智能硬件设施进行综合治理。 开发环境:因为我的项目应用了机器学习算法,所以对设施还是有点要求,目前自己的开发环境如下: 硬件环境: CPU:I7 9700KGPU:GTX1050TI内存:16G,500SSD软件环境: VS2015Arduino IDEUnity 3D 2019.204 零碎设计平台初步布局以家居的只能 AI 我的项目利用,通过家庭笔记本、网络监控摄像机、智能硬件设施、物联网终端设备、Agora 音视频平台等构建一套在家庭范畴内可用的智能治理平台。接入智能硬件设施、实时音视频通信、实时信令管制等次要性能,实现从设施治理到事件处理的残缺逻辑。 ...

December 2, 2021 · 2 min · jiezi

关于音视频:社交泛娱出海新引擎融云六化能力助开发者轻装上阵

广州,是社交泛娱乐出海的前沿阵地。广州开发者,是思考“社交泛娱乐出海制胜”最为集中的群体。【融云寰球互联网通信云】 2021 年 11 月 20 日,WICC 广州聚焦社交泛娱乐出海话题,紧扣 Z 世代和元宇宙的时代脉搏,揭秘了时代变局下,开发者须要的体系化配备及其正确打开方式。 在高峰论坛中,融云联结创始人兼 CTO 杨攀通过《通信服务生态进化 社交泛娱乐出海新引擎》的主题分享,明确了开发者须要的通信云服务“六化”能力——全球化、合规化、全栈化、场景化、模块化、集成化,为开发者的社交泛娱乐出海备好了“配备”。 (杨攀在 WICC 广州发表主题演讲) 融云提倡的开发者服务生态NO.1 全球化 如果从技术视角来看全球化,面对社交泛娱乐出海的开发者,通信云服务商往往被要求在“IM+RTC”根底能力之上,提供优质的网络传输能力,撑持“爽爆”的用户体验。 融云在寰球部署了数千个动静减速节点,在国内以及新加坡、北美等地均设有数据中心,可撑持寰球 233 个国家和地区的互通互联。目前,融云的寰球通信网已迭代至 3.0 版,基于 Anycast 的一体化减速网,攻克了网络连通率、数据传输延时、网络抖动、网络覆盖率、数据的实时监控、QoS 品质监测等多个技术难题,提供堪比运营商级别的网络传输能力和通信品质。 NO.2 合规化 融云通过五方面内容来阐释合规化,别离是:个人隐私、数据安全、数据主权、内容平安和通信安全。 (开发者服务生态-合规化) 「个人隐私」爱护,中国有《信息安全技术集体信息安全标准》,在海内,欧洲的 GDPR、美国的 CCPA 和 HIPAA,也都对个人隐私爱护提出了明确要求。作为通信云服务商,融云提供的底层服务均合乎这些法律法规的相干要求。 「数据安全」强调运营者对数据的存储和流转的解决。首先是杜绝数据透露。其次,无论国内还是国外,数据的存储、流动和流传,必须合乎相干法律法规的要求。融云在数据安全方面已获得包含 ISO 国内认证在内的所有相干认证,遵循要求做到数据安全合规是融云始终秉持的准则。 「数据主权」大多会关注中国、美国和欧盟的法律,然而新加坡、越南等国家也相继出台了法律,开发者须要足够器重和充沛钻研。 「内容平安」次要指融云联结业余合作伙伴为开发者提供的内容审核和过滤能力,包含图文音视,以及自定义的各种音讯。在语言上,具备解决不同语种,以及各语种混搭内容的辨认与审核能力。在审核模式上,可能针对不同的业务模型部署不同的审核策略。 「通信安全」针对时有发生的第三方歹意破解事件,融云从身份登录、链路平安,以及平台治理等不同方面,提供了业内最残缺的平安防护体系。 NO.3 全栈化 杨攀指出,对于全栈化能力的了解不该当只停留在技术侧,单纯看通信云厂商反对的平台数量。而该当从开发者的角度,深刻理解开发者不同的业务。 比方,跨平台开发会抉择 Flutter 和 React Native;游戏开发会用 Unity;做私域,做引流,会用到各个平台的小程序开发;而做物联网,则会选用 Linux。 也就是说,只有了解不同业务所对应的不同技术抉择,PaaS 服务能力在不同技术栈上,针对性地提供相干能力,让开发者用起来更得心应手。 要做到这一点,并非易事。比方,为了实现音视频 SDK 的高质量兼容,须要在各种浏览器的不同版本上做适配。为此,融云在音视频 SDK 每一次迭代中,都在这些平台上进行了大规模、残缺的自动化测试和验证。 (杨攀在 WICC 广州发表主题演讲) 融云的通信云服务能力NO.4 场景化 往年,融云在业内第一次提出了场景化 SDK 概念。依据不同场景,融云将本人的最佳实际间接封装成 SDK。语聊房、直播、呼叫三大场景化 SDK 横空出世,开发者无需本人再写代码,间接调用 API 接口,就能以更少的工夫老本,获取更便捷、更高质量的开发实效。 ...

November 30, 2021 · 1 min · jiezi

关于音视频:音视频系列五ffmpeg之rtmp推流阿里云转发vlc拉流播放

title: 音视频系列五:ffmpeg之rtmp推流阿里云转发vlc拉流播放 categories:[ffmpeg] tags:[音视频编程] date: 2021/11/30 <div align = 'right'>作者:hackett</div> <div align = 'right'>微信公众号:加班猿</div> 在前两篇 阿里云服务器搭建Nginx+rtmp推流服务器中,咱们曾经配置把阿里云的rtmp推流服务搭建好了,用的是PC软件OBS来进行推流到阿里云服务器,接下来就用雷神的最简略的基于ffmpeg的推流器,rtmp形式推流,阿里云服务器转发流,VLC拉流的流程走一遍。 链接地址:最简略的基于FFmpeg的推流器(以推送RTMP为例) https://blog.csdn.net/leixiao... 一、RTMP简介RTMP是Real Time Messaging Protocol(实时音讯传输协定)的首字母缩写。该协定基于TCP,是一个协定族,包含RTMP根本协定及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议,次要用来在Flash/AIR平台和反对RTMP协定的流媒体/交互服务器之间进行音视频和数据通信。反对该协定的软件包含Adobe Media Server/Ultrant Media Server/red5等。RTMP与HTTP一样,都属于TCP/IP四层模型的应用层。-- 百度百科 RTMP推流器(Streamer)的在流媒体零碎中的作用能够用下图示意。首先将视频数据以RTMP的模式发送到流媒体服务器端(Server,比方FMS,Red5,Wowza等),而后客户端(个别为Flash Player)通过拜访流媒体服务器就能够收看实时流了。 二、程序流程图RTMP采纳的封装格局是FLV。因而在指定输入流媒体的时候须要指定其封装格局为“flv”。同理,其余流媒体协定也须要指定其封装格局。例如采纳UDP推送流媒体的时候,能够指定其封装格局为“mpegts”。 av_register_all():注册FFmpeg所有编解码器。 avformat_network_init():初始化Network。 avformat_open_input():输出(Input)。 avformat_find_stream_info():查找流信息。 avformat_alloc_output_context2():调配输入 AVFormatContext。 avcodec_copy_context():复制AVCodecContext的设置(Copy the settings of AVCodecContext)。 avformat_write_header():写文件头(Write file header)。 av_read_frame():获取一个AVPacket(Get an AVPacket)。 av_rescale_q_rnd():转换PTS/DTS(Convert PTS/DTS) av_interleaved_write_frame():写文件尾。 三、代码#include <iostream>extern "C" {//蕴含C头文件#include "libavformat/avformat.h" #include "libavutil/time.h"};int main(int argc, char* argv[]) { AVOutputFormat* ofmt = NULL; //输出对应一个AVFormatContext,输入对应一个AVFormatContext //(Input AVFormatContext and Output AVFormatContext) AVFormatContext* ifmt_ctx = NULL, * ofmt_ctx = NULL; AVPacket pkt; const char* in_filename, * out_filename; int ret, i; int videoindex = -1; int frame_index = 0; int64_t start_time = 0; //in_filename = "cuc_ieschool.mov"; //in_filename = "cuc_ieschool.mkv"; //in_filename = "cuc_ieschool.ts"; //in_filename = "cuc_ieschool.mp4"; //in_filename = "cuc_ieschool.h264"; in_filename = "./ouput_1min.flv";//输出URL(Input file URL) //in_filename = "shanghai03_p.h264"; //out_filename = "rtmp://localhost/publishlive/livestream";//输入 URL(Output URL)[RTMP] out_filename = "rtmp://阿里云服务器IP:1935/live";//输入 URL(Output URL)[RTMP] //out_filename = "rtp://233.233.233.233:6666";//输入 URL(Output URL)[UDP] //注册FFmpeg所有编解码器 av_register_all(); //Network avformat_network_init(); //输出(Input) if ((ret = avformat_open_input(&ifmt_ctx, in_filename, 0, 0)) < 0) { printf("Could not open input file."); goto end; } if ((ret = avformat_find_stream_info(ifmt_ctx, 0)) < 0) { printf("Failed to retrieve input stream information"); goto end; } for (i = 0; i < ifmt_ctx->nb_streams; i++) if (ifmt_ctx->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO) { videoindex = i; break; } av_dump_format(ifmt_ctx, 0, in_filename, 0); //输入(Output) avformat_alloc_output_context2(&ofmt_ctx, NULL, "flv", out_filename); //RTMP //avformat_alloc_output_context2(&ofmt_ctx, NULL, "mpegts", out_filename);//UDP if (!ofmt_ctx) { printf("Could not create output context\n"); ret = AVERROR_UNKNOWN; goto end; } ofmt = ofmt_ctx->oformat; for (i = 0; i < ifmt_ctx->nb_streams; i++) { //依据输出流创立输入流(Create output AVStream according to input AVStream) AVStream* in_stream = ifmt_ctx->streams[i]; AVStream* out_stream = avformat_new_stream(ofmt_ctx, in_stream->codec->codec); if (!out_stream) { printf("Failed allocating output stream\n"); ret = AVERROR_UNKNOWN; goto end; } //复制AVCodecContext的设置(Copy the settings of AVCodecContext) ret = avcodec_copy_context(out_stream->codec, in_stream->codec); if (ret < 0) { printf("Failed to copy context from input to output stream codec context\n"); goto end; } out_stream->codec->codec_tag = 0; if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER) out_stream->codec->flags |= AV_CODEC_FLAG_GLOBAL_HEADER; } //Dump Format av_dump_format(ofmt_ctx, 0, out_filename, 1); //关上输入URL(Open output URL) if (!(ofmt->flags & AVFMT_NOFILE)) { ret = avio_open(&ofmt_ctx->pb, out_filename, AVIO_FLAG_WRITE); if (ret < 0) { printf("Could not open output URL '%s'", out_filename); goto end; } } //写文件头(Write file header) ret = avformat_write_header(ofmt_ctx, NULL); if (ret < 0) { printf("Error occurred when opening output URL\n"); goto end; } start_time = av_gettime(); while (1) { AVStream* in_stream, * out_stream; //获取一个AVPacket(Get an AVPacket) ret = av_read_frame(ifmt_ctx, &pkt); if (ret < 0) break; //FIX:No PTS (Example: Raw H.264) //Simple Write PTS if (pkt.pts == AV_NOPTS_VALUE) { //Write PTS AVRational time_base1 = ifmt_ctx->streams[videoindex]->time_base; //Duration between 2 frames (us) int64_t calc_duration = (double)AV_TIME_BASE / av_q2d(ifmt_ctx->streams[videoindex]->r_frame_rate); //Parameters pkt.pts = (double)(frame_index * calc_duration) / (double)(av_q2d(time_base1) * AV_TIME_BASE); pkt.dts = pkt.pts; pkt.duration = (double)calc_duration / (double)(av_q2d(time_base1) * AV_TIME_BASE); } //Important:Delay 延时 if (pkt.stream_index == videoindex) { AVRational time_base = ifmt_ctx->streams[videoindex]->time_base; AVRational time_base_q = { 1,AV_TIME_BASE }; int64_t pts_time = av_rescale_q(pkt.dts, time_base, time_base_q); int64_t now_time = av_gettime() - start_time; if (pts_time > now_time) av_usleep(pts_time - now_time); } in_stream = ifmt_ctx->streams[pkt.stream_index]; out_stream = ofmt_ctx->streams[pkt.stream_index]; /* copy packet */ //转换PTS/DTS(Convert PTS/DTS) pkt.pts = av_rescale_q_rnd(pkt.pts, in_stream->time_base, out_stream->time_base, (AVRounding)(AV_ROUND_NEAR_INF | AV_ROUND_PASS_MINMAX)); pkt.dts = av_rescale_q_rnd(pkt.dts, in_stream->time_base, out_stream->time_base, (AVRounding)(AV_ROUND_NEAR_INF | AV_ROUND_PASS_MINMAX)); pkt.duration = av_rescale_q(pkt.duration, in_stream->time_base, out_stream->time_base); pkt.pos = -1; //Print to Screen if (pkt.stream_index == videoindex) { printf("Send %8d video frames to output URL\n", frame_index); frame_index++; } //ret = av_write_frame(ofmt_ctx, &pkt); ret = av_interleaved_write_frame(ofmt_ctx, &pkt); if (ret < 0) { printf("Error muxing packet\n"); break; } av_free_packet(&pkt); } //写文件尾(Write file trailer) av_write_trailer(ofmt_ctx);end: avformat_close_input(&ifmt_ctx); /* close output */ if (ofmt_ctx && !(ofmt->flags & AVFMT_NOFILE)) avio_close(ofmt_ctx->pb); avformat_free_context(ofmt_ctx); if (ret < 0 && ret != AVERROR_EOF) { printf("Error occurred.\n"); return -1; } return 0;}四、运行后果 ...

November 30, 2021 · 3 min · jiezi

关于音视频:干货回顾-社交产品出海机会再思考

随着海内社交市场由蓝海变成红海,增量市场逐步往存量市场转变,社交产品出海还有机会吗?如何更深刻地了解社交产品?本文整顿自「社交产品笔记」主理人宁凯伦在量江湖、拍乐云主办的《社交产品如何引爆海内指标市场》线上研讨会上的演讲,次要分享了对社交产品的市场剖析、机会剖析和产品思考。 PART 01 出海社交市场现状目前社交产品的同质化十分重大,不论是产品性能,还是经营形式,海内市场曾经不再是一个蓝海了,早在2年前就曾经是一片红海了。 依据APP Annie最新的「海内公司社交榜单」,能够看到目前做社交产品的公司,头部也就几家,包含赤子城的Mico、欢聚的Hago等。除了这些还有一些比拟低调的,做得好的就三四家,月流水在千万级别。青出于蓝的比方YoYo,从印度转入中东,做得十分不错,量级快赶上头部了。接下来是「Dating APPs下载榜」。而在支出方面,左滑右滑的模式仍然是最支流的,比方Bumble和探探。上榜的Tapple、Pairs和With这三家是日本做得最好的社交软件,可见日本国家尽管不大,对社交需要还是很高的。想要浸透日本市场很难,但后劲微小。这是前不久APP Annie刚出的「中国出海厂商下载榜」,其中亚洲翻新团体就有三款——Uplive、CuteU和Lamour。此外,Litmatch当初的量也快靠近千万日活,号称“海外版的Soul”,但我感觉它更像最晚期的Soul,后续也肯定会改版。 PART 02 出海社交产品机会回到社交出海产品的模式,咱们会发现还是那些:1V1视频、语聊房、秀场直播、左滑右滑、灵魂匹配/占卜、婚恋,其实婚恋比拟少。目前没有太多新的产品模式,去谋求景象级的模式也不太好找,至多在短期内不容易呈现。尽管看起来产品同质化,市场被洗了一遍又一遍,但我认为社交市场永远是有机会的,不会有一个超级头部的公司来垄断这个行业。社交市场肯定存在机会,无论国内还是国外。咱们在钻研社交市场时,总结出产品参杂的这些因素:无聊、孤单、荷尔蒙。每个用户所须要的每一种因素的量是不一样的,有的用户可能孤独感比拟强,无聊、荷尔蒙比拟弱。用户对社交的需要是周期稳定的、矩阵状的。回归到产品,去思考怎么找产品、怎么做产品。咱们发现十年前,大家做产品时根本是看到一款产品,而后立马去复制,疾速地抢占这个市场。 这种模式叫:景象——重构——了解,在晚期是能够复用的,但当初的市场环境来说曾经很难有成果了,我会更推崇第二种模式:景象——了解——重构。图片 晓得它的数据、性能和渠道还远远达不到“了解”层面,“了解”次要体现在两方面:一个是用户模型,搞懂做这款产品的价值是什么;另一个是交易模型,搞懂怎么发明价值,以及价值如何去调配。咱们在做一款产品的时候,首先确保对用户的了解肯定是很透彻的,用户需要不是空穴来风的。无聊、孤单、荷尔蒙是每一个用户都会有的产品需要,但它们参杂在一起时它的化学反应是不一样的。所以咱们在做产品时,须要对景象进行拆解、还原。很多社交公司其实并没有用研和行研部门,用研部门的公司可能只是简略的电话访谈,就得出结论,而这个论断只是后果,不代表论断。论断是须要长期通过主观、主观的形式去验证的。后果不是很重要,重要的是论断。不要紧盯着后果去做,也不要被后果所蛊惑而影响了产品人的决策。 PART 03 UGC or PGC?再讲一下整个社交行业的一些变动曲线。做社交次要还是两个方向:UGC和PGC。从Match到婚恋交友到QQ空间(晚期也是社交产品)到YY、六间房、Bumble、Azar、陌陌......我看到一个景象,做UGC起家的产品,最初会往PGC上靠。因为UGC的社交产品中,女性用户是外围资源,一旦她们的体验不好,就会导致散失,从而导致整个平台产品用户的散失。所以很多UGC产品前面体现得不是很好,比方陌陌,在2016-2017年时数据不好的时候,引入了PGC直播性能,目前产生流水的次要是靠直播。UGC的生命周期很短,而PGC的生命周期更长。很早之前的六间房、9158目前都在存活,Soul、积目、Yalla也都是最近几年比拟火的PGC产品。Yalla的用户量级其实并不是很高,次要靠中东的土豪来维持。在2020年的时候Yalla上市,很多做语音房的公司都跟着涌入中东,但最终存活率比拟低。这也看出,当初的社交行业曾经不是一个“重构”的时代,而是一个“了解”的时代。咱们在做产品的时候,更多的是要了解市场用户的需要、市场环境是怎么样的,有很多的考量,而不是简略的复制。心愿大家做产品时,可能有更粗浅的思考。无论是什么产品,它肯定都是在满足市面上用户的需要,从用户端来找产品方向肯定是正确的。多了解社交用户的需要,思考怎么样去满足。心愿大家能做出更好的产品,也能在海内走得更远。

November 25, 2021 · 1 min · jiezi

关于音视频:声网Agora-实时音视频服务正式上线-HTC-VIVE-Sync-App支持非-VR-用户

寰球实时互动云服务开创者和引领者声网Agora(纳斯达克股票代码:API)发表其视频 SDK 现已集成到当先的 VR/XR 近程合作及会议利用 HTC VIVE Sync App 中。 通过集成声网Agora 的视频 SDK,HTC VIVE Sync App 能够反对 HTC VIVE 用户和非 VR 用户在同一虚拟环境中进行更严密无缝的近程合作,用户在不须要穿戴 VR 设施的状况下也可能与其余 VR 用户共享沉迷式体验。此外,用户也能够在协同环境中实现屏幕及文档共享,让所有参与者都能够更不便、快捷地感触沉迷式体验,进步沟通效率和生产力 。HTC VIVE Sync App 搭载声网Agora 实时音视频技术,将虚构和事实世界无缝相连,打造完满的近程协同工具。 声网Agora 创始人兼 CEO 赵斌示意: “扩大事实与实时互动的联合,将推动下一代工作协同形式的翻新与改革 。同时,与 HTC VIVE 的严密单干及 XR 直播的倒退,让咱们感到无比振奋。咱们看到,通过声网Agora,人类在事实世界与 Metaverse 元宇宙间的实时互动、互连将变得触手可及。” 上个月,声网Agora 退出了HTC VIVE 的 ISV 合作伙伴打算。继上次单干落地,此次 HTC VIVE Sync App 对于声网 SDK 的集成和利用,标记着声网Agora 在帮忙寰球开发者创立更易于拜访、更具创新性和性能更弱小的实时互动利用方面迈出了重要的一步。随着市场对实时互动相干场景的需要一直减少,越来越多的人在尝试通过更加翻新及丰盛的模式放弃互连、互动。因可能提供沉迷式的体验,扩大事实已逐步成为公众间风行的一种互动形式。 HTC 首席执行官王雪红示意: “声网Agora 的实时互动解决方案是连贯事实和虚拟世界的桥梁,它可能为每位用户带来对于虚拟世界的独特视角并赋予其与之互动的能力。此外,声网Agora 实时互动解决方案简略易用,也是咱们创建人与世间的连贯与交互中重要的一环。” HTC VIVE 打造了寰球首个虚拟现实平台与生态,为企业和消费者带去无可比拟的 VR 沉迷体验。VIVE 生态系统基于高端 VR 硬件、软件及优质内容构建而成。VIVE生态系统涵盖了当先的扩大事实(XR)系列硬件产品、VIVEPORT VR 利用商店、面向企业客户提供解决方案的 VIVE Enterprise、领有 1 亿美金创投基金反对的VR/AR加速器 VIVE X 以及专一于开发及发行娱乐、游戏及商用内容的工作室 VIVE STUDIOS,和提倡文化艺术推广的 VIVE ARTS。 ...

November 22, 2021 · 1 min · jiezi

关于音视频:一起听一起看一起唱掀起Z世代青年社交浪潮

6月5日,声网Agora 联结人人都是产品经理在成都举办了主题为“社交泛娱乐APP经营增长力和新玩法解析”的沙龙。现场围绕社交泛娱乐新玩法解析以及出海的新机遇、领取痛点、增长、经营等多个环节深入探讨,干货满满。现场吸引了100多位成都本地的社交泛娱乐畛域从业者参会。 本次沙龙共邀请到声网Agora 社交泛娱乐产品专家高圣恺、Airwallex 商务总监Raven Liu、亚马逊云科技-四川泛娱乐行业业务拓展总监王磊、AdTiming 总裁助理,前Camera 360海内市场总监闫雯四位嘉宾别离就实时互动玩转泛娱乐场景、海内领取环境对泛娱乐出海的影响、如何疾速构建泛娱乐利用、产品经营增长的方法论等议题进行分享。 实时互动赋能社交、游戏、直播畛域场景翻新社交泛娱乐畛域始终是互联网行业热门的风口,在资本层面始终备受关注。高圣恺首先在现场分享了国内外互联网行业的投融资详情,依据CAICT的数据显示,受疫情影响,在2020年Q2-Q3国内互联网投融资金额的增长较为迟缓,但在2020年Q4,互联网投融资体现回暖,投融资金额大幅攀升,环比大涨86.2%,同比增长117.8%。Blued、Yalla Group等社交平台在2020年下半年相继上市,社交平台Soul也在往年5月提交招股书。 随着疫情的常态化以及实时互动技术的遍及,社交泛娱乐畛域也在往年催生了更多新的互动场景,例如Watch party、互动播客、Mateverse等,高圣恺在现场也别离通过社交、游戏、直播三个畛域联合声网的业务教训以及对行业趋势的洞察,分享了国内外社交泛娱乐畛域正在衰亡的社交互动新玩法。 在社交畛域,传统的语聊房场景借助实时互动技术,催生出游戏陪玩、心动信号、关系拍卖等不同场景的语音社交玩法,吸引更多“Z世代”年老用户的参加;往年爆火的“互动播客”展示了音频内容市场的后劲,在原有的音频播客“耳朵经济”根底上,加上互动直播,晋升了用户参与度、应用频率、以及社区粘性;在线K歌场景,越来越多的互动玩法正在退出到K歌当中,通过多人排麦、轮唱、抢唱或独唱等模式实现趣味互动,实现从唱到玩的互动降级,声网在往年更推出首个残缺的实时独唱解决方案,实现端到端超低延时,实在还原线下 KTV 场景;同时在在线音乐、在线视频平台,一起看电影、一起听音乐等陪伴型社交玩法正在受到当下年轻人的青睐。 在游戏畛域,以95、00后为主的年老新世代更青眼于轻松、趣味社交模式。通过小游戏+语音互动等形式为用户发明丰盛和关闭的娱乐场景,开释社交压力的同时减少趣味性和沉迷感,除了用户熟知的线上狼人杀玩法外,线上剧本杀、Pia戏、你演我猜等新的游戏社交玩法正在衰亡;在很多中重度的游戏场景中,游戏语音曾经成为十分重要的性能,用于玩家进行游戏战术的沟通以及游戏内的社交,而在海内市场,游戏内开虚构演唱会的玩法也正在流行,美国驰名歌手Travis Scott就在《堡垒之夜》游戏中开起了虚构演唱会,通过虚构的人物形象、炫酷的游戏内舞蹈动作与服装等,吸引了少量玩家在游戏中观看。 此外,在全民直播的时代,自习直播、硬件+健身直播、互动电商直播、赛事直播、云演唱会也成为直播互动新玩法。以赛事直播为例,在海内市场,“一起看较量”正在成为球迷青睐的线上观赛新玩法,VIP用户能够邀请好友一起看较量,一边享受超低延时的较量直播,一边与好友视频/语音聊天评论,单方放弃超强的同步性,共享每一个欢呼时刻;在疫情的推动下,云演唱会也在成为新的线上演唱会直播玩法,通过“观众多视角互动观看”、“智能应援棒近程打call”、“直播现场百人互动大屏”、“观众虚构形象,实时互动”等性能能够实现高沉迷感、互动玩法丰盛的云演唱会体验。 业界当先的实时互动技术+产品赋能泛娱乐翻新场景面对不断创新的社交泛娱乐场景,声网领有丰盛的API组合,能够帮忙开发者疾速创立各类实时互动场景,同时凭借自建的软件定义实时网 SD-RTN™、自研语音引擎Nova以及极速直播、低码高清、水晶球等业界当先的产品与技术能够满足开发者多样化的实时互动场景需要,并保障稳固、晦涩、超低延时的实时互动体验。 语音/视频通话、互动直播、极速直播满足不同场景的互动体验 针对社交泛娱乐场景不同的互动体验,声网提供了丰盛的实时互动产品组合。延时<400ms的强互动场景,对(可感知)延时的容忍为零,开发者可间接应用声网的语音通话与视频通话产品;延时在400ms-800ms之间的中互动场景,观众须要与主播放弃较强同步性,或者随时须要与主播连麦的场景,可接入声网的互动直播产品;针对延时800ms-3000ms的轻互动场景,观众可接受肯定延时,但主播须要依据状况及时回应观众文字/弹幕等信息,可接入声网的极速直播产品。 极速出图&低码高清保障晦涩高清的视频体验 声网“极速出图”利用先进的编码技术和传输算法,整体优化网络传输和Last Mile传输策略,进一步升高首帧出图工夫和切频道出图工夫,并且无效晋升码流俯冲速度,用户对图像切换零感知。 声网“低码高清”交融多种 AI 视觉算法和智能码控技术,在服务端对实时媒体流进行转码解决,实现等同画质下,无效节俭直播码率50%。 自研语音引擎Nova™:提供媲美业余播客设施的音质体验 声网自研的语音引擎Nova™可实现雷同码率下,音频采集与无效频率范畴更优( 32khz采样率),捕获更多语音细节,保障声音的高保真度。同时NOVA™ 语音引擎还能够在采样率肯定状况下,码率更小,可保障用户在弱网条件下保持良好的音频体验。 声网Agora 还能够提供HD音质的音频服务,最高能力MOS*评分为 4.7,VoIP电话MOS分通常介于 3.5-4.2 之间。 3A算法+AI降噪算法打消乐音与回声 声网Agora 领有业界当先的 3A 算法,智能适应各类环境,全面打消回声,并提供超一流的双讲体现;可在不伤害语音音质的状况下,无效打消各类乐音;可实现音频的自动增益,即便在嘈杂环境下用户也能体验优异。同时声网的AI降噪算法将心理声学与深度学习技术相结合,通过特征提取、神经网络以及增益调整对实时音频进行解决克制噪声,冲破了传统信号处理计划的性能瓶颈,从而为实时音视频提供清晰语音环境。 大咖分享,把脉泛娱乐利用领取、经营、增长等痛、难点Airwallex 商务总监Raven Liu也在现场分享了中国、印尼、马来西亚、泰国等亚太地区的领取趋势,并从领取形式的多元化、付款网络的全球化、自动化付款形式、一站式治理资金收付等角度分享了泛娱乐企业海内领取的痛点。亚马逊云科技-四川泛娱乐行业业务拓展总监王磊则联合了亚马逊云科技在寰球云计算畛域的业务教训分享了企业构建泛娱乐利用时在国内外市场可能会遭逢的挑战,例如初创的出海企业在寰球部署利用的工夫、运维、人力、资金等老本过高,会错失市场时机,以及泛娱乐企业如何疾速使用新技术(数据分析与机器学习等)升高经营老本,进步用户感触等;AdTiming总裁助理闫雯,前Camera 360海内市场总监闫雯先是分享了后疫情时代,社交泛娱乐APP的发展趋势,并从如何读懂用户、如何造就用户的被动行为、如何教育用户等角度分享了泛娱乐产品在产品经营与用户增长方面的方法论。

November 15, 2021 · 1 min · jiezi

关于音视频:网易云音乐音视频算法的-Serverless-探索之路

简介: 网易云音乐最后的音视频技术大多都利用在曲库的数据处理上,基于音视频算法服务化的教训,云音乐曲库团队与音视频算法团队一起合作,一起共建了网易云音乐音视频算法解决平台,为整个云音乐提供对立的音视频算法解决平台。本文将分享咱们如何通过 Serverless 技术去优化咱们整个音视频解决平台。 作者:廖祥俐策动:望宸 网易云音乐最后的音视频技术大多都利用在曲库的数据处理上,基于音视频算法服务化的教训,云音乐曲库团队与音视频算法团队一起合作,一起共建了网易云音乐音视频算法解决平台,为整个云音乐提供对立的音视频算法解决平台。本文将分享咱们如何通过 Serverless 技术去优化咱们整个音视频解决平台。 本文将从三个局部向大家介绍: 现状:音视频技术在网易云音乐的利用状况,引入 Serverless 技术之前遇到的问题; 选型:调研 Serverless 计划时的思考点; 落地和瞻望:咱们进行了哪些革新,最终的落地成果和将来布局。 现状作为一家以音乐为主体的公司,音视频技术被广泛应用于网易云音乐的泛滥业务场景里,为了更形象的让大家感触到,这里列举了 5 个常见的场景: 默认状况下,用户听到的是咱们采纳音频转码算法事后转好的标准化码率的音质,但因为流量无限或本身对于音质更高的要求,想要切换到差一些或更好的音质。 用户能够应用云音乐 APP 外面的听歌识曲性能去辨认环境中的音乐,这背地应用到了音频指纹提取及辨认技术。 在平台上的一些 VIP 歌曲,为了能给用户更好的试听体验,咱们会做副歌检测,让试听间接定位到低潮片段,这里用到了副歌检测算法。 在云音乐的 K 歌场景里,咱们须要对音频的音高进行展现并辅助打分,这里咱们用到了音高生成算法去欠缺 K 歌的根底数据。 为了更好的满足云音乐平台上,小语种用户的听歌体验,咱们为日语、粤语等提供了音译歌词,这里用到了主动罗马音的算法。 从下面的场景能够看到,音视频技术被广泛应用于云音乐的不同场景外面,施展了重要的作用。 从咱们的音视频技术做一个简略划分,能够分为三大类:剖析了解、加工解决、创作生产,这些一部分是以端上 SDK 的形式,在端上进行解决;而更多的局部,是通过算法工程化的形式,采纳后端集群部署治理,以服务的模式提供通用的音视频能力,而这部分是咱们明天分享的重点。 音视频算法的服务化部署工作中,须要理解很多相干音视频算法的特点,如部署环境、执行工夫、是否反对并发解决等,随着咱们落地算法的减少,咱们总结了以下法则: 算法的执行工夫长:执行工夫往往与原始音频的时长成正比,云音乐很多场景下音频、视频的时长 Range 范畴是很大的,基于这个特点,咱们在执行单元的设计上,往往都采纳异步化的模式。 音视频算法具备多语言个性:云音乐的算法包含了 C++、Python 等语言,对接环境上下文会带来极大的困扰,为了解决这个问题,咱们采纳标准化约定及镜像交付的形式,解耦各类环境筹备的工作,所以后续对于是否反对镜像部署,会成为咱们技术选型的一个重点考查。 弹性的诉求正在变大:云音乐平台的歌曲,从我入职时候的 500w,到当初在线超过 6000w,增量 vs 存量的 gap 越来越大,当咱们疾速施行一个算法时,不仅要思考增量的接入,更要思考存量的疾速解决,所以在零碎设计中,会独自把执行单元的最小粒度剥离进去,便于疾速的扩容。 基于咱们对工程化的了解,及音视频算法解决的特点,云音乐的音视频解决平台的整体架构如下: 对于不同音视频算法解决的独特局部,咱们做了对立的设计,包含算法解决的可视化、监控、疾速试用和解决数据统计等,对于资源的调配也设计了对立可配置的管理模式,让整个零碎的公共局部能够尽可能形象并复用。 整个音视频算法解决平台最要害的,也是明天的分享重点,是执行单元的交互与设计。云音乐通过对立的对接规范、采纳镜像交付的形式,解决了很多对接和部署上的效率问题。针对资源的应用,因为咱们一直有新算法、存量/增量服务的存在,在上云之前,用的是外部公有云云主机申请/回收、内容容器化的形式。 为了更好的形容云音乐执行单元的运行流程,咱们将它更细化下,如下图所示: 通过音讯队列去解耦了执行单元与其余零碎的交互,在执行单元外部,咱们通过管制音讯队列的并发度去适配不同并发性能的算法,尽量管制执行单元的次要工作仅用于算法的计算,这样最终在零碎扩容的时候,咱们可能做到最小粒度的扩容。 在这个模式下,咱们落地了 60 多种音视频算法,尤其是在近一年来,服务化的算法占到了一半,这些算法向云音乐 100+ 的业务场景提供了服务能力。但更简单的算法、更多的业务场景,对咱们的服务化效率、运维部署和弹性能力都提出了更高的要求,在咱们上云之前,在外部曾经用到了 1000 台以上不同规格的云主机及物理机。 选型随着业务场景和算法复杂度的减少,尽管通过了很多形式去简化了外部业务场景、算法等的对接,但越来越多夹杂存量、增量解决的算法,不同流量的业务场景规模,以及不同业务场景可能会复用同一类算法的,让咱们在解决机器资源的工夫,远比咱们在开发的工夫更多。 这个也促使咱们开始去思考更多的形式办法,去解决咱们遇到的问题,最间接的有三个痛点。 ...

November 11, 2021 · 1 min · jiezi

关于音视频:视频通信关键技术探索及实践

导读:2021年10月21日,「QCon 寰球软件开发大会」在上海举办,网易智企技术 VP 陈功作为出品人发动了「AI 时代下的交融通信技术」专场,邀请到多位技术专家与大家一起分享相干技术话题。 咱们会针对四个演讲专题逐个进行介绍与分享,本期是咱们的第二期,视频通信关键技术摸索及实际。 嘉宾介绍:韩庆瑞,网易云信音视频实验室,高级技术专家。 前言无论在娱乐社交、线上学习,还是近程银行等生存场景中,视频都已成为最重要的互动形式之一,用户对于视频成果也提出越来越高的要求。延时低,弱网反抗能力强,视频画质清晰等也让企业面临很高的技术挑战。 作为交融通信云服务专家,网易云信的业务笼罩了次要的视频场景,包含低延时的实时音视频场景,容许局部延时的直播场景和不强调延时的点播场景,本文介绍了网易云信视频在各个场景下的关键技术和利用尝试。 网易云信视频技术部署下图为网易云信整个交融通信的主网图。右边和左边是端侧的设施,能够接入任何设施,手机、pad、PC、web 等。核心这部分是服务器,其中有编译的转发服务器还有 MCU 服务器,如果牵涉到肯定时延会转推到互动直播的服务器。云信的视频技术在 RTC 场景下次要部署在端侧,如果是是直播点播的业务,云信次要提供直播转推部署的视频转码服务。 RTC 场景的视频技术上面介绍网易云信在 RTC 场景上面的视频技术,次要分为三点。 新一代的音视频 SDK 架构下图是网易云信的音视频 SDK 架构图。去年年底,网易云信公布了新一代的音视频 SDK——G2。在这个 SDK 架构外面分为五层,其中媒体引擎层是外围所在地,次要分为三个视频引擎,视频、音频和流传引擎。 网易云信视频引擎架构和利用场景下图是云信的一个视频引擎的架构。次要分为五大模块,视频前解决、视频编码、视频 QoE、视频解码、视频后处理。从采集端输出,云信反对的业务次要是分为两种,一种是从摄像头采集的实在的画面,另一种是从屏幕分享采集的画面。采集的画面会先送入视频前解决,云信业务散布在寰球,有各种设施,有一些低端设施也有一些入门级的设施,因为摄像头的起因导致采集的画面变差,为了晋升和复原这样的画质,视频前解决实现了画质解决后进入编码压缩,会传送给网络。 因为各种网络的影响,咱们会有一个视频 QoE 模块,保障云信用户都有一个完满的视频体验。通过网络传输到了对端之后进行解码,做一个后处理。后处理次要为了加重或者晋升因为网络压缩传输带来的画质的损失。 下图是视频引擎的利用场景,云信的视频场景分为4种,一种是实时通信利用场景,一种是低延时的利用场景,还有视频会议相干的,互动直播类的场景以及互动教学类低延时的直播场景。 视频引擎的关键技术视频前解决视频前解决次要是为了晋升实时视频端到端的视频成果。网易云信全球化的业务中,各种各样的设施都会接入,咱们须要这样的视频前解决来晋升画质。 视频 AI 加强这种技术是比拟古老的技术,很多年前就开始钻研了。随着 AI 技术和深度学习的提高,视频加强技术有了极大的晋升。然而深度学习或者是 AI,运算量太大,云信的业务遍布寰球,各种设施都会接入,尤其是挪动端,像印度市场,东南亚市场中入门级设施比拟多。 这些挪动端对功耗和性能都十分敏感,略微大一点的运算量,功耗和电量就会掉得很快,这导致呈现了大模型,一个比拟好的深度学习模型就很难在这些场景着落地。如果采纳一些小模型,成果又不能失去保障。 咱们的业务是通信业务,须要传到对端去。单纯加强兴许成果好,但传到对端成果不肯定好。通过解码后的图像,尽管有加强成果,但它的块效应比没有加强的更重大,在本端体现可能比拟好,然而高频重量变多,后果导致了压缩率过高,损失过大。 云信通过两个办法来解决以上问题。一是训练易过拟合,另一个是加强后主观可能变差。 首先有一个场景辨认模块,能够辨认出一些文字区域的内容、静止场景和游戏场景,针对每种不同的场景会有不同的模型。比如说游戏场景是一种模型,文字场景是一种模型,兴许是同样的模型然而可能参数不一样,这样能够保障运算能力足够,同时成果也不错。 咱们的模型是采纳的是小模型。后面提到模型不能太小,太小了表达能力不好,因而咱们的模型是一种“轻量级模型”,参数量是1-2K,实际上达不到这种小模型成果,因为业界的很多小模型参数不到1K,可能只有几百,它的网络水平是三到四层。因为咱们有自研的高效的推理框架 NENN。它和开源的推理框架相比,对小模型做了独有的优化,保障小模型的速度比其余开源框架速度快得多。 视频降噪因为有的设施或者摄像头在暗场景下噪声比拟多,须要高频噪声打消掉不必要的 bit。如果进行降噪,有利于编码,有利于传输,有利于进步主观品质。 在 RTC 场景中降噪是一样的,挪动端业务居多,很多地区是入门级的设施,对性能功耗十分敏感,简单功耗无奈应用的,速度快的算法,成果又不好。如果采纳不适合的降噪可能不仅把噪声抹除掉了,也可能把有用的高频重量缩小,这样对整个视频品质会带来不好的影响。 网易云信在关注这个问题时,咱们是从人眼主观的感觉来思考的。从人眼主观来说,人眼观看是有区别的,一些场景下人眼的分辨率很高,分辨出很多高频系数。另一些场景中,人眼分辨率很低,分辨率会急剧下降。 网易云信采纳了人眼敏感性分析方法,可能提取出像素级图像中的人眼敏感区域,咱们宁愿将降噪的系数升高,宁愿放过一些噪声,也不违心就义掉高频系数。即便放掉了,人眼也感觉不进去,咱们也有一个非常简单但十分高效的噪声预计算法,这样的两种办法产生了一个权重值,因而视频速度会很快,而且成果也不错。 视频编解码云信的视频编码反对支流编码器,包含利用最宽泛的264和265,还有基于对 RTC 的深刻理解,开发了自研的编码器,叫 NE264CC。 云信编码器的速度十分快,咱们的品质能够晋升50%,跟265相比,咱们编码速度能够快60倍。下图是咱们自研的 NE264,这是一个十分优良的协定,在行业界存在了20年,经久不衰,它也是目前笼罩最多的一种实时通信协议。云信在264根底下面研发了 NE264编码器,有疾速模式决策、高效亚像素搜寻、自适应参考帧、 CBR 码控。 ...

November 10, 2021 · 1 min · jiezi

关于音视频:深入理解-TCP-拥塞控制

随着网络技术的飞速发展,越来越多的工作依赖网络实现,基于互联网的实时通信零碎的品质和实时性也很大水平也依赖于网络品质。然而,在Internet的TCP/IP体系结构中,拥塞的产生是其固有的属性。网络拥塞是指用户对网络资源(包含链路带宽、存储空间和处理器解决能力等)的需要超过了固有的解决能力和容量, 相比UDP,TCP本身具备拥塞管制机制,并且须要保障数据牢靠传输,这会对基于TCP的音视频实时传输造成肯定的困扰。本文将深刻解说TCP的拥塞管制机制以及如何基于TCP传输来设计一个实时音视频零碎。 PART 01 TCP拥塞管制简介TCP/IP协定栈开始宽泛运行后,网络开始蒙受拥塞解体;即数据发送主机会以倡议容许的速度将其数据包发送到互联网,当某些路由器产生拥塞,导致数据包被抛弃;对于TCP这种有重传机制的传输协定,当产生数据失落时,重传数据将缩短数据达到的工夫;同时,高频率的重传,也将导致网络的拥塞得不到缓解,从而引发更多的拥塞。为了防止这类问题,1980年代前期,TCP拥塞管制被引入到网络协议中。 从狭义上讲,TCP拥塞管制的是让每个源确定网络中有多少可用容量,以便它晓得能够平安传输多少数据包,避免过多的数据注入到网络中,使网络中的路由或者链路不至于过载。在网络中产生拥塞时,拥塞管制缩小向网络中发送数据的速度,避免造成恶性循环;同时在网络闲暇时,进步发送数据的速度,最大限度地利用网络资源。当然,确定可用网络容量并非易事,一直有新的TCP连贯的退出和缩小;更蹩脚的是,可用带宽会随着工夫的推移而变动,这意味着任何给定的源都必须可能调整它在传输中的数据包数量。 PART 02 TCP拥塞控制算法分类实践上,拥塞管制有两种实现形式: 端到端拥塞管制:在这种拥塞管制办法中,由发送端本人来判断是否拥塞,而后调整传输速率;网络辅助的拥塞管制:由网络中的路由器来通知发送方,网络的拥塞状况。通过网络层反馈拥塞信息实现拥塞管制的办法,须要失去网络设备的反对,革新底层硬件;当初罕用的TCP协定大都采纳的是端到端拥塞管制,即由发送端本人来判断是否拥塞;若发送端检测到这种景象,就应该升高发送数据的速率,若没有,则能够缓缓进步速率。拥塞控制算法须要解决以下三个问题: TCP如何限度数据的发送速率;TCP如何检测网络中是否拥塞;TCP采纳什么算法来调整速率(什么时候调整,调整多少)。TCP拥塞控制算法倒退的过程当中呈现了以下几种不一样的思路: 基于丢包的拥塞管制:将丢包视为呈现拥塞,采取迟缓探测的形式,逐步增大拥塞窗口,当呈现丢包时,将拥塞窗口缩小,如Tahoe、Reno、BIC-TCP、Cubic等;基于时延的拥塞管制:将时延增长视为呈现拥塞,延时增长时增大拥塞窗口,延时缩小时缩小拥塞窗口,如Vegas、Westwood等;基于链路容量的拥塞管制:实时测量网络带宽和时延,认为网络上报文总量大于带宽时延乘积时呈现了拥塞,如BBR;基于学习的拥塞管制:没有特定的拥塞信号,而是借助评估函数,基于训练数据,应用机器学习的办法造成一个控制策略,如Remy。 PART 03 常见TCP拥塞控制算法TCP RenoReno算法所蕴含的慢启动、拥塞防止和疾速重传、疾速复原机制,是现有的泛滥基于丢包的拥塞控制算法的根底。发送方维持一个叫做拥塞窗口cwnd(congestion window)的状态变量和慢开始门限ssthresh状态变量。ssthresh的用法如下: 当cwnd<ssthresh时,应用慢开始算法。 当cwnd>ssthresh时,改用拥塞防止算法。 当cwnd=ssthresh时,慢开始与拥塞防止算法任意。 (1)慢热启动算法 – Slow Start连贯建好的开始先初始化cwnd = 1,表明能够传一个MSS大小的数据。 每当收到一个ACK,cwnd++; 呈线性回升。每当过了一个RTT,cwnd = cwnd*2; 呈指数回升。 (2)拥塞防止算法 – Congestion Avoidance当cwnd >= ssthresh时,就会进入“拥塞防止算法”。算法如下: 收到一个ACK时,cwnd = cwnd + 1/cwnd当每过一个RTT时,cwnd = cwnd + 1 (3)拥塞状态算法 – Fast RetransmitReno在收到3个duplicate ACK时就开启重传,而不必等到RTO超时。拥塞产生时: cwnd = cwnd/2sshthresh = cwnd (4)疾速复原 – Fast Recoverycwnd = sshthresh + 3 * MSS (3的意思是确认有3个数据包被收到了) 重传Duplicated ACKs指定的数据包;如果再收到 duplicated Acks,那么cwnd = cwnd +1;如果收到了新的Ack,那么,cwnd = sshthresh ,而后进入拥塞防止算法。 ...

November 10, 2021 · 1 min · jiezi

关于音视频:小谈音视频质量检测

自己从一位测试的角度登程,基于目前我的项目中摄像头的直播和语音对讲业务,正寻求音视频的品质测试及一些监控剖析伎俩。工作中发现达到肯定的并发水平之后,就会呈现延时、卡顿、丢帧、马赛克等问题。所以最近在网上看看专家的直播和专栏,学习一下行业内的好的测试方法。 这不,前几天有幸参加了声网的音频算法工程师赵晓涵的对于《实时语音品质监控零碎的过来、当初和将来》的在线直播和探讨。本次直播旨在介绍一下声网实时语音品质监控零碎的停顿,并和大家交换了一下将来的演变方向。 整顿了一下,本次直播次要的内容次要涵盖了以下几个模块: 1、过来:语音品质评估算法 2、当初:线下测试的线上化 3、将来:感知、反馈和监控一体化 一、过来:语音品质评估算法其中,过来的语音品质评估算法次要介绍了有参考主观评估办法、无参考主观评估办法和主观评估办法。 一千个观众会有一千个哈姆雷特,主观评估办法暂且不管。有参考主观评估办法中利用最宽泛的有 P.862 PESQ、PESQ-WB 这两种。12 年左右推出了最新的有参考评估办法 P.863 POLQA,它是基于 PSQM 的降级革新。它们都次要依赖无损的参考信号。而无参考主观评估办法无需参考信号。其中的 ANIQUE+据作者称,其准确度超过有参考的 PESQ,这一点也很有意思。 主观评估办法的痛点: 1、有参考办法:只能用在上线前 2、无参考办法-传统信号域:利用场景窄,鲁棒性差 3、无参考办法-传统参数域:仅在无限弱网条件下能够放弃精度 4、无参考办法-深度学习:利用场景和语料无限,复杂度高(信号域) 在语音品质评估算法这一方面,咱们真的是小白。基于目前业务的,次要笼罩还是功能测试、接口测试和流媒体的局部性能测试。利用现有算法对语音品质进行评估,临时可能还不会做。 2、当初:线下测试的线上化直播中赵晓涵老师在这一块次要回顾了下在设计这个零碎前的指标,和目前上下行链路的次要问题和解决办法。 现有的评估零碎的设计指标: 1、精度高:评估后果牢靠 2、笼罩业务场景广:游戏、娱乐、教育等业务场景 3、算法复杂度不能太高:不会对性能造成很大的升高 4、和语音内容弱相干能力:不论输出是语音、音乐还是噪声,剖析后果不能受影响。 上行次要有这几个流程:编码、传输、解码、播放 上行侧的品质评估办法也是次要依据下面四个模块开展的: 1、编解码器性能:不同的编解码器对不同的语料处理结果不一样 2、网络传输:丢包、抖动和提早等 3、弱网反抗算法品质:丢帧弥补 4、设施的外放能力:设施硬件差会对音质有所伤害 这一部分内容深有感触,咱们目前用到的摄像头来自海康、大华、雄迈、TPLink 等好几个厂商,同个厂商又有多种型号。不同设施都有硬件差别,就连根本的国标接入都会有些许异样,更别说在音视频上的体现了。目前咱们平台所用的视频编码正从 H264 到 H265 转变,音视频品质测试显得分外重要。 而网络传输也是咱们目前的性能测试常常遇到的瓶颈,尤其是是视频文件上传 s3 存储会很大水平受限于上行的带宽。另外还有应用 udp 传输,不可避免得造成数据的丢包等问题。 不同的终端设备,对音频外放的音质也不尽相同。这一点咱们在兼容性测试时曾经有所发现。 三、将来:感知、反馈和监控一体化对将来的零碎的指标: 1、外部状态更细:上行链路细节待优化。 2、体验笼罩更广:目前有些噪声还未能笼罩,待优化。 3、反馈速度更快:指标在 1 分钟内能收到反馈。 4、笼罩通话更全:指标是每一秒都能监控到。 一个笼罩广,响应快,又精准的平台会是所有平台的平台的指标,心愿能早日看到平台给音视频品质检测行业带来更大的促成。

November 4, 2021 · 1 min · jiezi

关于音视频:实时语音如何过质量关

大家好,我是 cv 君,涉猎语音一段时间了,明天提笔浅述一下语音的传输前后,品质如何过关,也就是说,怎么评估咱们语音的品质,比方麦克风等声音设施等等。 咱们在语音品质方面,有三种全局上的评估办法:有参考主观评估办法,有参考主观评估办法,主观评估办法。 那么咱们细分到他的子类,就会有很多应用的算法与评估思路。 语音品质极其重要,可能让聊天的你我免受一些噪声的搅扰,可能让部队军方的通信更牢靠,可能让每逢佳节倍思亲,与家人通电话时重温那久违,实在,亲切的话语和音色。 咱们过来是怎么评估的?主观评估钻研次要能够参照国 家安 全规范《YT 音频主观测试分析法》,国家倒退规范 次要内容也是一个参考国 际规范中的主观评估:国际标准广泛采纳的是 itu- t p800(电 话传输零碎中语音品质的主观评估)、(电话宽带和宽带数字语音编解码器 的主观评估)和 itu-t p805(对话品质的主观评估)。 cv 君到他们的官网找到了以前的评估办法,可是很全面的哦。 图 1 :YDT2309-2011 规范中的测试方法 评分标准 评分标准能够采纳 5 分或者 7 分,事后定义好评分值,则不须要归一化解决。否则须要做归一化解决 图 2 :YDT2309-2011 评分标准 评估维度 《审计主观判断评估国家标准》依据理论产品列出了许多须要删减或减少的维度。 cv 君认为,主观的测试规范通 常分为词的品质和词义。这 些页面首先探讨单词的品质。许多独特的教训规范和相干的教训。 这些页面是独特质量标准的一部分。 良好的基于价值的指标 实用的欧盟规范 1-65899 寰球音量测试能够分为一个或多个动静级别,在应用最宽泛的音频规范中,一般音频程序都是从不同的流动角度进行训练的。 主观评估-基于模型(一) 背景及规范 最早的语音品质评估规范仅仅基于无线指标(rxqual) ,而理论语音通过无线、传输、替换、路由等程度流传节点传输,任何链路问题都会导致用户语言感知有余,仅思考无线指标是不可能发现和定位语音品质问题的,因而基于用户感知的语音品质评估办法已成为用户语音品质评估的最重要规范。 罕用的语音品质进行评估钻研办法能够分为主观评估和主观评估。语音教学质量的早期教育评估是主观的。人们可 以打电话后通过本人耳朵感觉到谈话的品质。1996 年,国际电信联盟开始工作。它是一种主观测试方法,用来考察和量化用户的听力行为和感知的语音品质。 要点:GSM 网络,一点比三点好~ 然而,在现实生活中,人们仿佛很难听到和观赏声音的品质,这就是为什么国际电信联盟曾经做了声音品质测试和标准化技术与,规范噪声评估算法,如 PESQ 等相继公布,评估从理论评估办法的对象登程,打消了应用量化算 法计算音频品质程度的弊病。 其中,算法是国际电信联盟 2001 年 2 月公布的最 新一代语音品质评估算法,因为其弱小的活动性和良好的连通性,采纳了最快的语音品质评估算法。在各种端到端网络中,为了主观地评估词的品质,词的品质和数量决定了词的品质。 通过建设算法模 型(见模板 6),咱们能够看到所有算法的流程,而后用输出滤波器模仿输出滤波器的电平,提取和提取这两种算法。信号。一般来说, 输入信号和参考信号之间有很大的差别,S 点是低的。因而,他们可能会感到困惑。咱们能够看一看这些来自舌头大学的图片。 ...

November 1, 2021 · 3 min · jiezi

关于音视频:语聊房高质量音乐伴奏的实现

看恐怖片关掉声音,再吓人的画面成果也会大打折扣;一片谐和舒适的画面中忽然呈现短促的转场音乐,观众会立刻体会这是要“小事不妙”了。 如果说每个人都有一首属于本人的 BGM,那不同场景、情景也都有能调动情绪、引起人们共鸣的音乐。 在近期大势的语聊房业务中,热门场景也都少了音乐的“陪伴”。在语音电台中,它能够衬托主题气氛,让用户更沉迷;在多人社交中,它能够毁灭尬聊,让交换更自在;在 K 歌房中,伴奏更是不可或缺的刚需。 而且,音乐是人类共通的语言,即使是出海业务中面对不同文化背景的用户,音乐也能够唤起多种要害情绪,是语音社交利用必备“技能”。 融云语聊房 SDK,以高扩展性笼罩全副热门语聊房场景,天然也在音乐治理方面下足了功夫,提供在线音乐、歌单治理能力;反对加载播放本地音乐,反对大部分文件类型;提供入场欢送、鼓掌、笑声等气氛音效;混音管制,反对人声音量、本端音乐音量、远端音乐音量、耳返开关。 如此丰盛的音乐治理能力,如何在技术侧保障优质音乐体验呢?本文将分享融云语聊房 SDK 的高质量音乐播放实现计划。 语聊房音乐播放的次要模式及解决难点语聊房业务场景中,音乐播放的模式次要有以下几种: 通过第三方设施播放音乐,通过外接声卡和主播声音混音,而后从主播端发送。 通过语聊房利用播放伴奏,在利用外部和主播的声音进行混音。 通过手机设施播放音乐伴奏,在设施采集时将主播的声音和设施的声音块采集到麦中。 通过 PC 端 Android 模拟器实现直播,PC 端播放伴奏,而后通过 PC 的内录形式采集音乐并和主播声音实现混音。 不同的实现形式,对音乐的解决流程存在着肯定差别。解决失当可能造成观众端音乐声音小、音乐高低音局部缺失、吞音等重大影响用户体验的景象。 一般而言,音频信号被挪动终端采集模块采集后,会通过回声打消、降噪、自动增益管制等预处理过程,再由音频编码器进行编码。 预处理过程蕴含 Acoustic Echo Cancelling(AEC,回声打消)、Automatic Gain Control(AGC,自动增益)、Active Noise Control(ANC,降噪),俗称 3A。 3A 预处理算法对设施采集的声音也会有不同水平的伤害。而且,相比语音通话场景,音频预处理会对音乐产生比拟显著的影响。比方,降噪、回声打消算法可能在主播唱歌时将伴奏音乐当成背景噪声解决掉,从而导致伴奏音乐缺失,音质重大升高等后果。 (回声打消原理) 所以,在有背景音乐这种绝对简单,对声音要求比拟高的场景,更须要精细化的预处理策略。 融云语聊房高质量音乐实现形式通过大量的技术和市场调研,咱们将语聊房音乐采集形式演绎为以下几种: 设施 Mic 采集的音源曾经是歌声和伴奏的混合声音,这种场景的混音次要有: 设施播放伴奏和主播歌声在空气流传中进行混音 设施播放伴奏通过外接声卡和主播歌声进行混音 通过 PC 内录环境将伴奏和主播歌声进行混音 设施通过 Mic 采集主播歌声,而后在利用内与利用播放的声音进行混音。依据主播的习惯又可将该利用场景分为主播有耳机和无耳机的音乐应用环境。 通过大量测试和实践验证,咱们采取的计划为:利用外音乐混音尽可能还原音源,利用内音乐混音则放在 3A 预处理之后混音的策略,在保障音质的根底上进步用户体验。 这是因为,利用内音乐和声音混音若在声音 3A 前进行的话,3A 预处理就会对音乐产生伤害,导致解决后的音乐呈现音量不稳固、局部音质失落等问题,而且也会对回声打消中的参考信号量产生影响,而导致聊天过程中呈现回声问题。这种状况下,将声音混音放在 3A 解决之后,不仅解决了聊天过程中的降噪问题而且能够保障音乐的音质,进一步确保用户取得高质量音质体验。 (利用内音乐和声音混音流程) 在利用内部音乐和声音混音的情景中,分为主播应用耳麦和不应用耳麦两种情景。 主播应用耳麦时,通过耳麦采集音源能够屏蔽掉背景噪声,而且不会存在回声问题。针对这种状况,对 Mic 采集到的伴奏和声音的混音不做降噪和回声解决,从而保障了混音音源的完整性。 针对主播不应用耳麦的状况,通过大量多型号设施测试,咱们调优了 3A 解决参数,最大限度保障音乐伴奏混音和通话流程的品质,做到音乐高音质播放,进步用户体验。 (利用外音乐和声音混音流程) ...

November 1, 2021 · 1 min · jiezi

关于音视频:如何-30-分钟搭建一个语聊房

一个领有 1-2 年教训的开发者,从 0 到 1 上线利用只有 7 天。一个刚起步的程序员,能够 30 分钟内实现一个 Demo。 这不是天方夜谭,而是融云场景化 SDK 带给行业的创变。【关注 融云寰球互联网通信云】 商业社会兵贵神速,特地是以 Z 世代人群为指标用户的语音社交类利用。国家统计局的数据显示,1995 年到 2009 年出世的 Z 世代人口靠近 2.6 亿。而相比“前辈”,他们的偏好更加共性、悦己、多变,社交上更考究圈子、同好。 语音社交因沉迷式的情感交互而被 Z 世代 pick,但利用要一直围绕支流模式尝试冲破,依附玩法翻新抢占先机,否则产品也就是“类卿”尔。 明天,咱们就追随融云场景化研发负责人臧其龙,具体理解融云语聊房 SDK,是如何实现全面笼罩语聊房业务场景,反对开发者疾速出活的。 语聊房理解一下带大家拆解这款“行业利器”之前,咱们先重新认识一下语聊房。 语聊房,从字面上看就是语音聊天房,外围是多人实时语音交互。疫情之下,随着 Clubhouse 的大火,语聊房业务迎来暴发期,语音社交胜利出圈。 (图 1 融云语聊房 Demo) 从上图看,语聊房 APP 的界面基本上由两局部组成。 上半局部次要是用户和麦位,比照生存中的场景,像一个有一位主持人和八位发言者的讲座,台下有若干听众;听众若有趣味发言,走上讲台,拿起麦克风就能够变成发言人。 下半局部则是一些惯例的聊天室模式,承当发送信息、发送礼物等性能。 开发这样一款产品,个别会面对什么问题呢? 首先是麦位信息同步。一个语聊房可能会有几千人在线,任何一个人上麦都须要在极短时间内把麦位信息同步给房间内所有人,这是第一个挑战。 其次是麦位治理。 上麦,意味着用户领有了公布音频流的能力,角色从观众切换为主播。 下麦则意味着主播变成普通用户,失去了公布音频流的能力。 锁麦,就是锁定麦位,任何人都不可以上麦。 闭麦,顾名思义,该麦位上的用户无奈发言。 邀请上麦,由房主邀请听众上麦互动。 还有一些音频类的惯例操作,比方静音、混音、播放音乐等。 语聊房产品的外围是麦位治理,融云的语聊房解决方案,就是通过上麦、下麦等一系列麦位治理来对用户和流进行同步治理的 SDK。 语聊房业务流程通过多年倒退,融云的 IM 和 RTC 曾经是行业基建。开发者应用 PaaS 服务商的这些能力,能够很不便地实现即时通讯和实时音视频的业务利用。 然而,把 RTC、IM 能力和场景玩法相结合的简单业务,实现起来仍然面临不小的艰难。基于对行业的深厚积攒和前瞻判断,融云推出下一代场景化 SDK 解决方案,首发场景聚焦与 Z 世代深度黏合的语聊房业务,满足开发者疾速实现业务的需要。 ...

November 1, 2021 · 1 min · jiezi

关于音视频:CDN边缘JavaScript敏捷交付实践

本文由百度智能云-视频云-内容散发减速技术架构师——高岩 在百度开发者沙龙线上分享的演讲内容整顿而成。内容从CDN利用Serverless的意义登程,具体介绍EdgeJS Serverless服务。文/ 高岩整顿/ 百度开发者核心视频回放:https://developer.baidu.com/l... 本次分享的主题是:CDN边缘JavaScript麻利交付实际,内容次要分为以下三个方面: CDN利用Serverless的意义EdgeJS Severless服务沉迷式CDN编程体验01 CDN利用Serverless的意义CDN根本介绍 CDN含意:是指一组散布在不同地理位置的服务器,协同工作以提供互联网内容的疾速交付。 CDN服务已失去一直遍及。现在,大多数web流量都通过CDN提供服务,简直所有的门户网站、罕用的视频 APP(例如,爱奇艺、抖音)都会用 CDN 架构实现更加疾速的内容散发,让用户更快地看到视频内容,带来更好的用户体验。 这是因为 CDN 容许疾速传输、加载互联网内容所须要的资源。以门户网站为例,咱们须要加载 HTML 页面、JavaScript、文件 css 等资源;而视频网站则须要加载缩略图、视频文件。 CDN 还可帮忙爱护网站免受某些常见的歹意攻打,例如分布式拒绝服务(DDOS)攻打。 应用CDN劣势: 缩短网站加载工夫通过将内容散发到访问者左近的CDN服务器(以及其余优化措施),访问者体验到更快的页面加载工夫。因为访问者更偏向于来到加载迟缓的网站,CDN 能够升高跳出率并减少人们在该网站上停留的工夫。换句话说,网站速度越快,用户停留的工夫越长。缩小带宽老本网站托管的带宽耗费老本是网站的次要费用。通过缓存和其余优化,CDN 可能缩小源服务器必须提供的数据量,从而升高网站所有者的托管老本。减少内容可用性和冗余大流量或硬件故障可能会扰乱失常的网站性能。因为CDN具备分布式个性,因而与许多源服务器相比,CDN 能够解决更多流量并更好地接受硬件故障。改善网站安全性CDN 能够通过提供鉴权、平安证书的改良以及其余优化措施来进步安全性。vCDN的倒退早在2009年,伯克利曾针对过后衰亡的云计算做过评论,并提出了以下6个潜在的长处: (实践上)有限可用的计算资源,可在资源池中实现任意的伸缩。用户再也不须要承当服务器运维的工作和责任。服务的按需付费成为可能。超大型数据中心的应用老本显著升高。通过可视化资源管理,运维操作的难度大大降低。分时复用,物理硬件的利用率大大提高。基于云计算的理念,能够实现一个虚拟化CDN(vCDN), 即可在专有、裸金属、虚拟化或基于容器的基础设施上运行CDN。vCDN作为云上的一个利用,是CDN和云紧密结合的产品。其次要性能个性包含:硬件虚拟化:虚拟化基础架构使软件和硬件性能得以合成,服务器运维大大简化。低提早:在共享基础设施上运行CDN性能,能够更快的调起其余利用,比方能够实时进行图片解决。弹性伸缩:能够按需应用CDN,在流量顶峰和低峰,进行主动的弹性扩容和缩容。 然而云计算技术倒退到明天,虚拟化并不能解决所有的问题,在对性能有特地高要求的场景下,面临的次要难点如下: 虚拟机/容器,构建业务利用运维老本较高。不能做到按需付费,依然须要独占虚拟机。开发简单,须要很多其它的依赖,在开发业务的过程中,须要数据库、对象存储等框架。须要本人掌控运维和应用状况,开发难度较高。Serverless介绍与特点为了解决上述问题,亚马逊的 AWS 在 2015 年推出了 lambda 服务,提出了Cloud Function的概念,引起了业界对于 Serverless 的关注宽泛。 Serverless 次要蕴含 Faas、Baas 两种状态。其中,Faas 将 Function 作为服务,Baas 将后端服务作为服务。 在利用了 vCDN 后,也能够用 Baas 的形式运行服务。Serverless 旨在让开发人员不须要再关注服务器,云会帮主动实现服务器的运维和伸缩。 具体而言,Serverless 具备以下特点: 计算的无状态化,服务的贮存和计算齐全离开部署的,开发者只须要关怀计算的实现,能够通过其它云上的独立服务进行贮存,容易进行迁徙和扩缩容。资源透明化的,无须要再关怀服务器、虚拟机、容器须要多少资源、带宽、磁盘空间,能够通过调用函数在平台内实现资源的主动治理。按需计费,依据调用时长、调用次数进行计费。目前,vCDN 能够为客户提供 Baas 服务。如果用户须要更通用的函数计算产品,举荐应用百度云的 CFC,能够配置 CDN 的触发器。CDN利用Serverless的意义 早在 2018年,云治理公司 RightScale 发展的一项考察显示,Serverless 是增长最快的公共云服务。据统计,AWS 上超过一半的用户曾经在应用 Serverless 服务。Serverless 始终在高速倒退,呈现出越来越大的影响力。Serverless 将无处不在,CDN也必须拥抱Serverless理念,提供边缘可编程能力,使用户能够在管制台上通过 API 设置代码,造成编程能力,更无效地管制 CDN。 ...

October 27, 2021 · 2 min · jiezi

关于音视频:免费报名与阿里云一同探索视频云的新技术与新场景

在过来的一年中,咱们能够看到多媒体特地是音视频技术的能力在严厉的挑战下,为各行各业带来了微小的变动。疫情过后,又会有哪些多媒体新技术、新实际出现在公众的视线当中?为行业的倒退与利用带来哪些新的趋势与机会? 10 月 29 日 - 30 日,LiveVideoStackCon 2021 音视频技术大会 北京站,一起探讨音视频行业与技术倒退的挑战和更多机会。 阿里云视频云专场:从上云到翻新,视频云的新技术与新场景10 月 30 日 | 北京 LiveVideoStack 将携手阿里云共邀 5 位技术大咖,一起探讨从上云到翻新,视频云的新技术与新场景。阿里云视频云依靠阿里云服务数百万开发者的卓越服务能力与实际,在本专场演讲中,将从云计算服务、网络调度到端侧出现等视频生产与生产的全流程角度登程,分享下一代技术趋势和判断,并从实际角度分享算法、架构、AI 等多个具备实际指导意义的话题。除视频云专场之外,阿里云视频云还将带来大会主题演讲《编解码再进化:Ali266 与下一代视频技术》,与泛滥行业专家独特探讨下一代音视频技术趋势。 ⏰ 流动工夫: 2021/10/30 14:00-18:00 参加形式: 线下参加(收费) 扫码立刻报名 此二维码仅为阿里云专场收费报名通道,大会通票需另行购票出品人. 何亚明/阿里云智能视频云资深技术专家 何亚明,阿里云智能事业群视频云资深技术专家,视频云技术研发负责人。退出阿里巴巴之前曾就任于美国 Facebook 和微软,在微软负责 Principal Software Engineer,从事视频编码和视频云的研发,在 Facebook 负责实时音视频和直播技术的研发,短短几年内将 Facebook Messenger 和 Facebook Live 两款产品从零打造成领有 10 亿级用户的明星产品。 讲师与议题 邹娟/阿里云智能视频云高级技术专家 邹娟,阿里云智能视频云高级技术专家、阿里巴巴团体内容架构组成员、阿里云视频云媒体生产平台研发负责人,从 0 到 1 主导了阿里云 AI 视频和云剪辑等重点产品的研发工作。具备多年传媒媒资治理与音视频内容生产平台的研发教训,曾作为核心成员主导了《新一代电视台网络化制播零碎及重大利用》等重大项目,荣获 2013 年国家科技进步一等奖等多个国家级奖项。 TOPIC:“三位一体”— 云原生视角下的视频生产与生产全流程技术实际. 视频服务有着人造的云服务属性,是 5G + 云原生时代最大的确定性和畛域,云原生实际也在极大地革新着视频生产的全流程。通过多年实际,阿里云视频云造成了云边端一体、软硬一体、网络与协定一体的视频从生产到生产的全流程技术服务,造成了丰盛的技术落地教训,领有了极具竞争力的场景实际。本演讲,将以实践与实际、技术场景深度联合的角度,全面介绍阿里云在视频畛域中的翻新之路。 王钊/阿里云智能视频云算法专家 王钊,阿里云智能视频云算法专家,毕业于北京大学,博士论文获评《北京大学优良博士学位论文》。从事 AI 视频编码,视频编解码规范,软件编码器和视频解决等畛域。研发的深度学习视频编码零碎在 CLIC2020 较量中取得亚军。加入 VVC 规范制订,JVET 神经网络视频编码组,MPEG 面向机器视频编码组。参加钉钉编码器优化,Ali266 编码器开发。发表顶级期刊、会议论文十余篇,获评 2016 VCIP Best 10% Paper Award, 2018 ICIP Best Student Paper Award。 ...

October 25, 2021 · 2 min · jiezi

关于音视频:AI-全栈-SOTA-综述-这些你都不知道怎么敢说会-AI语音识别原理-实战

章目录前言语音辨认原理 信号处理,声学特征提取 辨认字符,组成文本 声学模型 语言模型 词汇模型语音声学特征提取:MFCC和LogFBank算法的原理实战一 ASR语音辨认模型 零碎的流程 基于HTTP协定的API接口 客户端 将来实战二 调百度和科大讯飞API实战三 离线语音辨认 Vosk前言 语音辨认原理 首先是语音工作,如语音辨认和语音唤醒。听到这些,你会想到科大讯飞、百度等中国的平台。因为这两家公司占据了中国 80% 的语音市场,所以他们做得十分好。然而因为高精度的技术,他们不能开源,其余公司不得不花很多钱购买他们的 API,然而语音辨认和其余利用很难学习(我培训了一个语音辨认我的项目,10 个图形卡须要运行 20 天),这导致了民间语音辨认的发展缓慢。陈军收集了大量 SOTA 在以后畛域的原理和实战局部。明天让咱们大饱眼福吧! 语音采样在语音输入后的数字化过程中,首先要确定语音的起始和完结,而后进行降噪和滤波(除人声外还有许多噪声),以保障计算机可能辨认滤波后的语音信息。为了进一步解决,还须要对音频信号帧进行解决。同时,从宏观的角度来看,人们的语音信号个别在一段时间内是绝对稳固的,这就是所谓的短期平稳性,因而须要对语音信号进行帧间解决,以便于解决。 通常一帧须要 20~50ms,帧间存在重叠冗余,防止了帧两端信号的弱化,影响辨认精度。接下来是要害特征提取。因为对原始波形的辨认不能达到很好的辨认成果,须要通过频域变换提取特征参数。罕用的变换办法是提取 MFCC 特色,并依据人耳的生理个性将每帧波形变换为原始波形向量矩阵。 逐帧的向量不是很直观。您也能够应用下图中的频谱图来示意语音。每列从左到右是一个 25 毫秒的块。与原始声波相比,从这类数据中寻找法则要容易得多。 然而,频谱图次要用于语音钻研,语音辨认还须要逐帧应用特征向量。 辨认字符,组成文本特征提取实现后,进行特色辨认和字符生成。这一部分的工作是从每一帧中找出以后的音位,而后从多个音位中构词,再从词中构词。当然,最艰难的是从每一帧中找出以后的音素,因为每一帧都少于一个音素,而且只有多个帧能力造成一个音素。如果一开始是错的,当前很难纠正。如何判断每一帧属于哪个音素?最简略的办法是概率,哪个音素的概率最高。如果每帧中多个音素的概率是雷同的呢?毕竟,这是可能的。每个人的口音、谈话速度和语调都不一样,人们很难了解你说的是你好还是霍尔。然而,语音辨认的文本后果只有一个,人们不可能参加到纠错的抉择中。此时,多个音素形成了单词的统计决策,单词形成了文本 这容许咱们失去三个可能的转录-“你好”,“呼啦”和“奥洛”。最初,依据单词的概率,咱们会发现 hello 是最有可能的,所以咱们输入 hello 的文本。下面的例子分明地形容了概率如何决定从帧到音素,而后从音素到单词的所有。如何取得这些概率?咱们能数一数人类几千年来所说的所有音素、单词和句子,以便辨认一种语言,而后计算概率吗?这是不可能的。咱们该怎么办?那咱们须要模型: 声学模型cv 君置信大家肯定晓得是么是声学模型~ 依据语音的根本状态和概率,尝试获取不同人群、年龄、性别、口音、谈话速度的语音语料,同时尝试采集各种宁静、嘈杂、边远的语音语料来生成声学模型。为了达到更好的成果,不同的语言和方言会采纳不同的声学模型来进步精度,缩小计算量。 语言模型而后对根本的语言模型,单词和句子的概率,进行大量的文本训练。如果模型中只有“明天星期一”和“今天星期二”两句话,咱们只能辨认这两句话。如果咱们想辨认更多的句子,咱们只须要笼罩足够的语料库,然而模型会减少,计算量也会减少。所以咱们理论利用中的模型通常局限于应用领域,如智能家居、导航、智能音箱、集体助理、医疗等,能够缩小计算量,进步精度, 词汇模型最初,它还是一个比拟罕用的词汇模型,是对语言模型的补充,是一个语言词典和不同发音的正文。例如,地名、人名、歌曲名、热门词汇、某些畛域的非凡词汇等都会定期更新。目前,已有许多简化但无效的计算方法,如 HMM 隐马尔可夫模型。隐马尔可夫模型次要基于两个假如:一是外部状态转移只与前一状态相干,二是输入值只与以后状态(或以后状态转移)相干。简化了问题,也就是说,一个句子中一个词序列的概率只与前一个词相干,因而计算量大大简化。 最初,将语音辨认为文本。语音声学特征提取:MFCC 和 logfbank 算法原理 简直所有的主动语音识别系统,第一步都是提取语音信号的特色。通过提取语音信号的相干特色,有助于辨认出相干的语音信息,并将背景噪声、情感等无关信息剔除。 1 MFCC刚刚 cv 君说到了 MFCC, 这个很经典哦~ MFCC 的全称是“梅尔频率倒谱系数”,这语音特征提取算法是这几十年来,罕用的算法之一。这算法通过在声音频率中,对非线性梅尔的对数能量频谱,线性变换失去的。 1.1 分帧因为存储在计算机硬盘中的原始 wav 音频文件是可变长度的,咱们首先须要将其切割成几个固定长度的小块,即帧。依据语音信号变动快的特点,每帧的时长个别取 10-30ms,以保障一帧中有足够的周期,且变动不会太激烈。因而,这种傅里叶变换更适宜于安稳信号的剖析。因为数字音频的采样率不同,每个帧向量的维数也不同。 ...

October 25, 2021 · 8 min · jiezi

关于音视频:Android-音视频-EGL-源码解析以及-C-实现

OpenGL 是一个跨平台的 API,而不同的操作系统(Windows,Android,IOS)各有本人的屏幕渲染实现。所以 OpenGL 定义了一个两头接口层 EGL(Embedded Graphics Library)规范,具体实现交给各个操作系统自身EGL简略来说 EGL 是一个两头接口层,是一个标准,因为 OpenGL 的跨平台性,所以说这个标准显得尤其重要,不论各个操作系统如何蹦跶,都不能脱离我所定义的标准。 EGL 的一些基础知识EGLDisplayEGL 定义的一个形象的零碎显示类,用于操作设施窗口。 EGLConfigEGL 配置,如 rgba 位数 EGLSurface渲染缓存,一块内存空间,所有要渲染到屏幕上的图像数据,都要先缓存在 EGLSurface 上。 EGLContextOpenGL 上下文,用于存储 OpenGL 的绘制状态信息、数据。 初始化 EGL 的过程能够说是对下面几个信息进行配置的过程。 OpenGL ES 绘图残缺流程咱们在应用 Java GLSurfaceView 的时候其实只是自定义了 Render,该 Render 实现了 GLsurfaceView.Renderer 接口,而后自定义的 Render 中的 3 个办法就会失去回调,Android 零碎其实帮我省掉了其中的很多步骤。所以咱们这里来看一下残缺流程(1). 获取显示设施(对应于下面的 EGLDisplay) /* * Get an EGL instance */ mEgl = (EGL10) EGLContext.getEGL(); /* * Get to the default display. */ mEglDisplay = mEgl.eglGetDisplay(EGL10.EGL_DEFAULT_DISPLAY);(2). 初始化 EGL ...

October 22, 2021 · 6 min · jiezi

关于音视频:Android-音视频采集那些事

音视频采集在整个音视频解决的过程中,位于发送端的音视频采集工作无疑是整个音视频链路的开始。在 Android 或者 IOS 上都有相干的硬件设施——Camera 和麦克风作为输出源。本章咱们来剖析如何在 Android 上通过 Camera 以及录音设施采集数据。本章可联合之前公布的文章Android 音视频 - MediaCodec 编解码音视频做一个残缺的 Demo。 Camera在 Android 上的图片/视频采集设施无疑就是 Camera 了,在 Android SDK API21 之前的版本只能应用 Camera1 ,在 API 21 之后 Camera1 曾经被标记为 Deprecated ,Google 举荐应用 Camera2,上面咱们来别离看一下。 Camera1咱们先来看一下 Camera1 体系的局部类图。 Camera 类是 Camera1 体系的外围类,该类还有好多外部类,如上图: Camera.CameraInfo 类表白 Camera 的前后(facing)和旋转(orientation)等 Camera 相干的信息。 Camera.Parameters 类是 Camera 相干的参数设置比方设置预览 Size 以及设置旋转角度等。 Camera 类领有关上 Camera、设置参数、设置预览等 API,上面咱们来看应用 Camera API 关上零碎照相机的流程。 1.在开启 Camera 之前先开释 Camera,这一步的目标是重置 Camera 的状态重置 Camera 的 previewCallback 为 null。 ...

October 20, 2021 · 4 min · jiezi

关于音视频:音视频学习-弱网对抗技术相关实践

背景介绍实时音视频通话在以后的生存中是无时不刻存在的,包含社交、安防、交通等等各个方面都须要。用户场景复杂多变、要求严苛、网络环境不统一等给实时音视频通话带来很大条件。咱们在这方向略微做了一些工作,尽管和其余大厂的优化工作相比,咱们还处于劣势,还有很多能够优化和改良的,然而目前的一些停顿和工作内容和大家分享一下。 0.1 网络传输:咱们晓得网络传输目前有 TCP 和 UDP 两种,相干优缺点如下脑图;而影响网络传输品质也有很多起因:包含网络拥塞、网络丢包等等。这些因素间接决定以后实时视频通话的品质,也会给用户带来很大的体验影响。这也是咱们为什么要进行优化的根本起因了。 0.2 弱网定义:对于实时音视频通话来说:网络的复杂性、异构性、协定局部不规范性、网络异样,网络谬误等各种网络环境被毁坏的个性都称之为弱网。弱网环境无奈提供高质量的网络传输,对于接收端就是无奈收到间断的媒体包,造成声音异样、视频马赛克、花屏、黑屏等景象,对于音视频实时通话来说是十分致命的,间接影响到用户的体验,造成产品质量问题或者客诉问题。 0.3 实时音视频特点对于实时音视频通话来说要求最高的条件低提早和高质量,这一对个性的存在就是天生的矛盾结合体。高质量就要求发送端尽可能发送高分辨率,高质量的音视频流,对于带宽和网络环境要求比拟高,不容许有各种丢包、高抖动的景象存在;而低提早则对于网络环境没有那么严苛,是容许存在肯定丢包量、容许肯定范畴内的接管抖动的,否则只能用空间换工夫,导致音视频实时性时效,无奈达到低提早的要求。所以这是一对矛与盾的故事。只能在矛上寻求冲破,在盾上给予爱护,能力满足这样刻薄的条件。 一 FECwebrtc FEC 的实现形式有三种:RED(rfc2198)、ULPFEC(rfc5109)、FLEXFEC(还未通过)。然而 Ulpfec 是套用了 RED 的壳进行传输的,所以咱们采纳的是 ULPFEC 进行 FEC 爱护。 其基本原理是:在发送端,针对媒体包减少肯定冗余 FEC 包,FEC 包是通过异或 XOR 失去的。如果在网络传输过程中丢掉了一部分媒体包,则在接收端通过接管到的媒体包和 FEC 包进行异或 XOR 失去失落的媒体包,这样就不必发送 NACK 重发包占用网络资源了。 因为这部分在 WebRTC 中曾经实现的比拟好,只须要进行兼容性测试即可,这部分没有作为重点优化对象,沿用 WebRTC 中内容即可。 二 NACK2.1 NACK 介绍:NACK 代表否定确认。 它是 WebRTC 中的谬误复原机制之一。NACK 是接收端表明它没有收到特定数据包的一种形式。 NACK 音讯通过 RTCP 发送给媒体的发送方,后者须要依据其在缓存中的可用性以及对重传有用性的预计(是否能够应用)来决定是否重传失落的数据包 它已经收到。发送端保护一个缓冲队列,如果重发包在缓冲队列中则从缓冲队列中取出再次发送;如果没有在缓冲队列中,则不再发送,这样解码端就无奈收到重发包了。 2.2 优化和改良:因为以后零碎中采纳的依然是旧版本中的 NACK 流程,具体流程如下: RTP 模块解封包后,将数据包依照达到程序顺次传送到 JitterBuffer 模块中;每个数据包在插入 JitterBuffer 模块时都须要进行序列号的比拟和排序,如果序列号比拟新的数据包,则进行 NACK 构建,以上次保留的序列号+1 为起始值,以新收到的序列号为完结,将之间的序列号先缓存到 missing_sequence_numbers 中;WebRTC 在 JitterBuffer 中采纳线程查问的形式,每个肯定工夫进行一次遍历,确认以后 nack List 中是否存在以后工夫节点没有依照程序收到的数据包,如果存在就会组装并发送 NACK RTCP 包到发送端,申请发送对应的为接管到的数据包。NACK 是一个未达到数据包的确认过程,原先流程中有很多嵌套性能,或者流程简单的中央,因而咱们再了解的根底上做了两次优化,其两轮优化的大略流程图如下: ...

October 18, 2021 · 1 min · jiezi

关于音视频:别再傻傻分不清-AVSx-H26x-MPEGx-了

在音视频倒退的历程中,编解码无疑是其最外围的性能,编解码规范的更新换代也极大促成了音视频技术的倒退以及行为模式的变更。从电视到网络视频以及当初的网络直播、点播、音视频会议等等,这些变动的背地都离不开音视频编解码技术的更新迭代。比方 H.264(依然是目前应用最多的编解码标准)以及 H.265/HEVC(局部大厂在应用 优酷 腾讯等),以及国内的 AVS 系列。 h.26x 系列视频编码标准的倒退简史 LoveYFan H.261-视频编奠基者H.261 设计的目标是可能在带宽为 64kbps 的倍数的综合业务数字网(ISDN for Integrated Services Digital Network)上传输品质可承受的视频信号。编码程序设计的码率是可能在 40kbps 到 2Mbps 之间工作,可能对CIF和QCIF分辨率的视频进行编码,即亮度分辨率别离是 352x288 和 176x144,色度采纳4:2:0采样,分辨率别离是 176x144 和 88x72。 H.261 在图像编码上应用了咱们当初比拟相熟的离散余弦变换(DCT)算法, 它在起初的 JPEG 编码中起次要作用。但不止于此,它引入了一系列针对视频的个性,奠定了古代视频编码的根底,其中次要有宏块(Macroblock)和基于宏块的静止弥补(Motion Compensation)。 H.261 应用 YCbCr 色彩空间,并采纳4:2:0色度抽样,每个宏块包含 16x16 的亮度抽样值和两个相应的 8x8 的色度抽样值。YCbCr 又成为 YUV,依然是当初编解码标准所采纳的色调空间。宏块与基于静止弥补的帧间预测咱们晓得,视频是由一帧一帧的图像组成的组合,个别状况下一秒钟的视频中会蕴含 24、25、30、60 或更多张图片,它们依照肯定的工夫距离播放进去,基于视觉残留原理造成了晦涩、会动的画面。在间断的几帧之间,实际上存在着大量反复的画面,比如说上面这个例子: 一个红色台球在绿色桌面下面静止 用小球静止的方向和间隔来形容图像的变动 如果是以传统的思路对每一帧图像做压缩的话,显然整个视频在压缩过后仍存在大量的冗余。那么怎么办呢?H.261 规范引入了宏块的思维,它将整个画面切分为许多小块,而后再引入基于静止弥补的帧间预测——画面的大部分都是不动的,那么咱们将不动局部的区块沿用之前的压缩后果,动的局部用静止方向加间隔这样一个矢量来形容不就能够节俭出大量的存储空间了吗? DCT 算法 将 8x8 个像素分成一个块 DCT 算法起源于上世纪 70 年代,到了 80 年代中后期,有研究者开始将其用于图像压缩。这种算法能够将图像从空间域转换到频率域,而后做量化——缩小人眼敏感水平较低的高频信息,保留绝大部分低频信息,从而缩小图像的体积。最初再用高效的数据编码形式将解决过后的数据进一步压缩,这里应用了 Zig-Zag 扫描和可变长编码。在 H.261 及之后基于 H.261 框架的视频编码中,DCT 算法次要针对的是关键帧的压缩,所谓关键帧,就是在静止弥补中作为基准参考的一帧。打个比方,就像 Flash 动画中的关键帧一样,它定义了一个终点,后续的几帧都是基于这个关键帧演算进去的。因为它只做帧内压缩,不波及其余帧,又被称为 Intra-frame(帧内编码帧),简称 I 帧。 ...

October 15, 2021 · 2 min · jiezi

关于音视频:超低延迟直播架构解析

本文由百度智能云-视频云直播技术架构师——朱晓恩 在百度开发者沙龙线上分享的演讲内容整顿而成。内容从低延时直播背景与时机登程,剖析低提早直播技术,重点分享百度在低提早直播技术的实际工作。文/ 朱晓恩整顿/ 百度开发者核心视频回放:https://developer.baidu.com/l... 本次分享的主题是:超低提早直播架构解析,内容次要分为以下三个方面: 低提早直播背景与时机低提早直播技术剖析LSS低提早直播技术实际01 低提早直播背景与时机随着各行各业直播的遍及,加上疫情的强势推广。在线教育、直播带货、企业培训、线上招聘等实时互动的场景迅速升温。直播已成为企业数字化转型和内容营销的必备场景。 在直播中,用户实时互动体验始终是商家重点关怀的问题。例如直播带货过程中,主播曾经上完优惠券,10几秒过来了,用户却还在期待优惠券。超低提早直播能够大大晋升边看边买的体验,主播能够联合互动区更好实现控场和互动,并且让秒杀、抽奖、拍卖等对时效要求高的营销玩法有了更强的底层撑持,大大优化直播转换率。 又比方流动赛事直播场景中,电视/文字直播用户已在呐喊,而视频直播画面还未进球。超低提早能够极大的加深观众对于现场实时互动的沉迷感,参加比分和现场的互动,晋升用户对于线下流动的参与感。 而随着5G时代的到来,网络条件正疾速晋升:边缘带宽实现Mb向Gb增长,5G网络时延降落到1~10毫秒;依靠于AR、VR技术的直播更是大大晋升了用户的沉迷式体验。这些对低提早直播来技术,都是重大的时机。 02 超低提早直播架构解析RTMP/FLV直播提早起因剖析接下来,咱们以一个简略的直播架构为例,剖析传统的 RTMP/FLV 直播产生提早的起因。 架构介绍:主播通过 RTMP 推流到流媒体服务器,再从直播流媒体服务器通过 RTMP/HLS/FLV 等技术向观众散发包。而一个视频直播传输过程如下:视频输出摄像头采集数据——CDN传输——视频解码「设施端解决提早」、「网络层提早」和「服务器外部解决提早」。 缓存策略缓存策略次要指CND的GOP缓存,但这种缓存策略会减少提早。码率过高或 GOP 太短会造成 TCP 累积提早。TCP累积提早编解码过程中,解码端在显示之前的视频帧缓存和编码端的缓存都会造成提早。编解码缓存解码端在显示之前的视频帧缓存和编码端的缓存都会造成提早。编码编码环节中的 B 帧解码也依赖于前后视频帧的达到。因为以上起因,传统的基于 RTMP/FLV 的视频直播个别会产生 3-5 秒左右的提早。提早高的关键在于CDN的传输和播放解码没有很好地配合和互动。所以要实现低提早,次要解决这个关键问题。 低提早直播计划简略比拟——基于UDP基于 TCP 的视频直播存在较长的提早。为此,人们开发出了 SRT、QUIC、WebRTC 等一系列基于 UDP 协定的低提早直播计划。下表能够简略概述一下基于UDP的各项低提早直播计划的特点:介于WebRTC生态凋敝,百度抉择了WebRTC做为低提早,在下一章节会基于百度智能云音视频直播服务LSS,具体介绍低提早的直播计划实现。 03 LSS低提早直播技术实际LSS低提早直播方案设计指标与过程设计指标: 兼容已有直播业务,反对录制、截图、转码、RTMP/FLV等多协定散发。反对百万并发,实现直播的CDN散发。将提早管制在1s以内。实现过程:如上图所示,在典型的 LSS 直播推拉流的流程中 主播首先在主播端通过 LSS 推流 SDK 实现 RTMP 推流 ,在该过程中将实现实时美颜、实时滤镜、视觉特效、硬件加速等性能;视频流会被推到寰球智能接流网络中,进而接入 LSS 媒体核心,通过服务器端 SDK 实现实时转码、主动鉴黄、多码率输入、实时水印、实时截图、内容加密、录制点播、统计分析等性能,买通与点播、存储、RTC 等其它云服务产品的分割。接着,通过寰球智能散发网络,基于 RTMP/FLV/HLS/WebRTC 等计划将视频流散发到客户端,通过 LSS 播放器 SDK 实现 LSS 播放,在该过程中,将实现首屏秒开、追帧播放、自适应码率、解密播放等性能。直播场景革新 WebRTC 自身是面向多人会议的实时通信计划,为了使其更好地实用于直播场景,咱们须要对其进行一系列的革新,从而反对大规模的低提早直播散发。 就组件协定而言,采纳 AAC、H.264 音视频引擎、UDP 传输层协定、RTP 媒体协定、RTCP 数据协定。通过 STUN/ICE 实现建联,并且通过 HTTP 申请实现 SDP 协商。就QoS 计划而言,通过 NACK 的形式实现丢包重传。在播放侧进行基于 Jitter Buffer 的缓冲,在发送侧基于 PACING 机制调整发送的频率和码率,通过 GCC 实现拥塞管制,进而预计并反馈带宽。就具体的革新点而言,依然应用上行 RTMP 协定,反对非加密传输,音频转码反对 Opus,视频反对 B 帧,实现了 FLV timestamp 透传和 Metadata 透传。直播CDN反对与品质 ...

October 15, 2021 · 1 min · jiezi

关于音视频:声网-2020-实时大会后的弱网对抗实践

voip基于 IP 的音视频传输是一种实时视频通话技术,经由 Internet 协定来达成音视频通话,以及多媒体会议。VoIP 可用于包含 VoIP 电话、智能手机、集体计算机在内的诸多互联网接入设施,通过蜂窝网络、Wi-Fi、同轴电缆、光纤等设施进行信令传输、音视频通话、发送短信,以及局部管制信息的传输。 背景介绍一旦移动电话或者监控设施链接网络时,因为互联网的异构和各种媒介的传输效率的递加,必然呈现网络传输中音视频数据包的失落,因此间接影响用户的感官、以及主观体验。在 TCP 中有 ack 反馈进行验证包的完整性,而在 UDP 中减少 NACK 进行丢包的确认和判断,以及 RR 和 SR 相干的报告用于统计 RTT 相干数据。WebRTC 横空出世,以及自带的 JitterBuffer 和 NetEQ 的实现,让音视频 UDP 的传输有了足够的保障。 2020 年声网的 RTE 大会,有幸参加线上分享,学习到很多内容,其中音视频实时传输分会中提到的优化项,以及声网优化的后果对本人留下深刻印象。以下介绍一下过后看的 PPT,以及看完之后学习实时音视频之后针对性优化相干内容。 数据驱动来自北京大学王选计算机所的张行功老师介绍《数据驱动的实时视频传输技术》一章节。在互联网发达的当初,实时视频无处不在,包含不限于视频会议、视频直播、VR/AR、360°全景视频、以及音视频监控,音视频通话等。 然而实时视频传输面对很多挑战,包含:网络限度、不同网络之间传输提早、抖动比拟大,网络切换或 4G 网络丢包比较严重,视频传输品质低,容易卡顿、马赛克、黑屏、绿屏等景象,间接影响用户体验。TCP 尽管能够解决一部分问题,然而对于网络敏感水平却有待增强,同时会有肯定提早,不利于实时传输。WebRTC 的衰亡,能够解决大部分问题,包含基于丢包和时延的控制器,能够极大水平缓解。同时强化学习的引入进一步提高问题的解决能力。之后 BBR 模型对于传输提供很好的解决,包含低提早和高带宽。然而依然是基于 RTT 的模型,并没有公平性参考,适应性没有那么强。同时 BBR 是基于探测的形式,对于网络探测是滞后的。 参考模型而张老师团队提供的将数学模型与统计模型联合的 CC 提供了一个很好的思路。包含以公平性为指标函数的数学模型+无模型网络状态的统计模型联合,如下图所示: 该模型次要指标就是为了解决两个不可知和一个滞后的问题:包含用户不可知,网络状态不可知,以及网络情况反馈滞后。 优化晋升学习借鉴相干教训之后,对我司产品进行了优化,次要包含以下几局部: 第一步欠缺测试环境。因为我司产品大部分条件下都是有线连贯形式,而且有些是光纤染指,网络环境绝对比较稳定。所以在 Android 和 linux 产品中减少反对 Traffic Control 命令的形式进行数据发送端的网络模仿。TC 能够反对丢包、网络抖动、提早、带宽限度等多种形式,能够最大化靠近实时网络环境,进一步晋升实验室模仿的准确度和测试方法。为之后弱网优化提供更加健全、不便的测试伎俩,并且联合 TC 命令,实现测试 APP 的开发,能够联合命令进行随便设置,实现无开发教训的测试小姐姐也能够得心应手的测试验证。 ...

October 11, 2021 · 1 min · jiezi

关于音视频:音视频基础知识点

音频PCM:脉冲编码调制(Pulse Code Modulation)。通过采样、量化、编码将模拟信号转换为数字信号。依据奈奎斯特采样定理:为了不失真地复原模拟信号,采样频率应该不小于模拟信号频谱中最高频率的2倍。采样率:即采样的频率。因为采样率要大于原声波频率的2倍,而人耳能听到的最高频率为20kHz,所以为了满足人耳的听觉要求,采样率至多为40kHz,通常为44.1kHz,更高的通常为48kHz。采样位数:波形振幅在模拟信号上也是间断的样本值,而在数字信号中,信号个别是不间断的,所以模拟信号量化当前,只能取一个近似的整数值,为了记录这些振幅值,采样器会采纳一个固定的位数来记录这些振幅值,通常有8位、16位、32位。位数越多,记录的值越精确,还原度越高。声道数:反对能不同发声(留神是不同声音)的音响的个数。码率:即比特率,一个数据流中每秒钟能通过的信息量,单位bps(bit per second)。音频码率 = 采样率 采样位数 声道数视频分辨率:横向和纵向的像素数量,示意图像的精密水平。1080P 的 P 指 Progressive scan(逐行扫描),即垂直方向像素点,也就是 "高",所以 1920 * 1080 叫 1080P, 不叫 1920P。码率:概念同音频的码率。帧率:单位工夫内帧的数量,单位为:帧/秒 或fps(frames per second)。RGB:红、绿、蓝三原色。通过R G B三种根底色,能够混合出所有的色彩。YUV:一种亮度与色度拆散的色调格局。 Y:亮度,就是灰度值。除了示意亮度信号外,还含有较多的绿色通道量;U:蓝色通道与亮度的差值;V:红色通道与亮度的差值。因为人眼对亮度敏感,对色度不敏感,所以缩小局部UV的数据量,人眼是无奈感知进去,这样能够通过压缩UV的分辨率,在不影响观感的前提下,减小视频的体积。RGB和YUV的换算: Y = 0.299R + 0.587G + 0.114BU = -0.147R - 0.289G + 0.436BV = 0.615R - 0.515G - 0.100B——————————————————R = Y + 1.14VG = Y - 0.39U - 0.58VB = Y + 2.03U

October 7, 2021 · 1 min · jiezi

关于音视频:音视频终端引擎优化实践

本文由百度智能云-视频云终端技术架构师 ——李明路,在百度开发者沙龙线上分享的演讲内容整顿而成。内容从音视频终端引擎的概念登程,梳理了音视频终端引擎的倒退和技术演进,重点介绍了音视频终端引擎的关键技术组件,分享了开发过程中的教训与实际。文/ 李明路 整顿/ 百度开发者核心 视频回放:https://developer.baidu.com/l... 本次分享的主题是:音视频终端引擎优化实际。内容次要分为以下五个局部介绍: 音视频终端引擎介绍视频云音视频终端引擎倒退视频云音视频终端引擎面向企业级架构思考视频云音视频终端引擎关键技术组件视频云音视频终端引擎面向开发者提供服务01 音视频终端引擎什么是音视频终端引擎定义:音视频终端引擎,是一款集成在挪动或嵌入式设施中,应用软件定义的办法,扩大终端原有音视频解决能力,以高效地形式解决异构音视频场景下的归一化、抽象化、层次化的客户端问题。 正文: 归一化:指提炼不同音视频场景背地的主线逻辑。抽象化:采纳虚构映射的形式,定义不同音视频实体与组件内部分割。层次化:通过顶层架构的设计,实现不同音视频业务与接口内生关系。音视频引擎终端引擎根本架构首先看图片的顶端,这一条链路很好的解释了在上一章提到的归一化:音视频终端是从业务中迭代进去的,通过一些方法论,还要可能回归到业务当中。 在这条链路上,列举了几个常见的业务场景:点播、直播、短视频、实时音视频等。随着这些音视频场景的不断丰富,业务也会越来越简单,可能提炼不同音视频场景背地的主线逻辑就显得非常重要。 接下来,咱们重点剖析音视频终端引擎架构。 音视频框架首先要立足挪动端提供的零碎能力,包含零碎框架和硬件能力。如图,零碎框架层有iOS/Android的一些多媒体框架、硬件的编解码、硬件的解决能力如CPU、GPU、NPU的解决模块,以及一些开源图像库。 零碎框架层之上是第三方框架,如FFmpeg、OpenSSL(加解密);在点播场景用的比拟多的Ijkplayer/Exoplayer;用于底层通信的技术:双向、低延时的WebRTC技术,用于单向点播的RTMP,目前比拟火的SRT低延时计划;除此之外,还会有一些图像处理方面的框架如GPUImage等。 在此之上,就是一些跟场景相结合比拟多的模块,这里大抵列出了局部外围模块。 数据从多媒体采集模块进去,会通过一路或多路的混音混流(与理论场景相结合),而后过渡到多媒体编辑模块:当下短视频的一些能力(比方:转场、字幕成果增加等)都是通过多媒体编辑这个处理单元实现,再到前面的多媒体后处理模块:例如AR特效,以及一些比拟好玩的互动能力等;内容生产实现后,咱们会依据点播、直播或者短视频等场景的不同,采纳不同协定进行散发。 再上面就是生产侧,这里能够间接读取数据,也能够间接读取数据作为缓存放慢二次读取数据的载入。获取数据后会依据不同的封装格局,如FLV、TS或者是MP4等对数据进行解封装,再进行解码和渲染操作。 相比于其它挪动端框架,音视频框架最特地的中央就是管线局部,因为音视频SDK的产品与其它产品不太一样,首先须要的是实时处理,数据流是一直在各个模块之间穿梭的,如何保障各个模块间的高效传输,这里提出了一个管线的概念。 那么,是不是有这样的根本架构后,就能解决当初音视频场景的能力呢?答案当然是否定的。事实上,这套架构中,在软件层面、硬件层面都或多或少面临着挑战。具体来说,大抵能够分为以下几种: 1.平台能力不对齐尽管当初很多的平台都提供了大量的音视频解决能力,然而这些平台的能力并不对齐。上面以苹果iOS零碎的多媒体框架和Android多媒体框架解决1080p的高清视频举例说明。 iOS零碎多媒体框架:领有AVAsset, AVCapture 接口,通过这些接口可能很疾速获取到高分辨率视频的裸数据。Android零碎多媒体架构:不足像苹果这样的简略高效接口。通常须要两步解码,并且针对高分辨率的视频可能会解码失败。2.编解码芯片适配难编解码芯片简单且多变,很多厂商会依据本人的平台/产品进行二次定制,导致音视频编解码芯片的规范是对齐的。这对于开发者和云厂商来说,适配的技术老本十分高。 3.CPU到GPU性能开销解决难尽管说当初很多的高端手机都能提供十分多的协处理器,能力也十分强。然而针对音视频场景,性能开销的解决却有肯定挑战。比方视频的采集,通常是在CPU解决,然而若想做一些减速解决,须要在GPU进行。从CPU到GPU这种数据的转化协同,如果解决的计划不是特地好,会导致性能的开销十分大。 4. OpenGL图像处理框架挑战频频OpenGL是比拟老旧图像零碎框架,目前遇到了十分大的挑战。苹果在ARM11处理器上已提出自研的Metal解决框架,并把OpenGL图像处理框架标记为将来可废除。若OpenGL在将来废除,势必会影响目前大多数主流产品的稳定性。 音视频终端引擎新挑战简略介绍了音视频SDK的框架,接下来介绍目前框架遇到一些问题和挑战。 更高的音画规范目前很多业务场景,其实都在谋求更多的新玩法。会谋求更大的分辨率,还有一些更高的刷新率,甚至是更极致的体验。比方:有些场景像点播或短视频,720p的分辨率曾经不能满足场景的应用,甚至在一些静止场景,30fps的刷新率也曾经没方法满足场景的开发。但音视频SDK很大水平上会受制于平台的能力,因为平台具备很多差异性,以及相干硬件没有齐全遍及,所以导致音视频SDK在倒退过程当中,其遇到很多的问题。 另外多模块间的数据交互到模块间的数据交互也是一个微小挑战,如何保证数据无损解决和高效传递? 跨屏的音画场景除了方才说音视频本身的高清技术标准的降级外,音视频终端也在缓缓的摸索一些沉迷式场景体验,这也催生了一些新的平台和新的交互方式。比如说一些带屏幕的智能音箱,用户能够在这种类型的设施上就会有一些新的需要:更好的场景渲染、更好的通话质量、更低的播放时延。还有目前比拟风行的数字人:如何在户外大屏幕,甚至在一些专有设施上以更高精度的形式出现进去? 这些音视频终端数据跨屏,迫使音视频终端引擎反对更多的硬件平台、更多的个性适配、更好的人机交互。但受限于设施兼容性,如何保证数据的高效计算和稳固传输?这些都是音视频终端引擎须要面对的问题。 02 视频云音视频终端引擎倒退通过上一章的介绍,置信大家对音视频终端引擎有肯定的理解。在本章将梳理百度视频云做音视频引擎的倒退过程,并筛选几个重要节点介绍具体的利用计划。 视频云音视频终端引擎倒退路线图百度智能云在较早的时候就提出过音视频解决方案,下图形容了次要的倒退历程。阶段1:OneSDK音视频解决方案 提供推拉流能力,在千播大战和直播答题等场景有宽泛的利用。 阶段2:一站式解决方案随着当初短视频、互动直播、以及其余实时音视频场景的一直的丰盛。百度提供了更全面的一站式的解决方案,其中包含了特效、编辑和连麦的能力。 阶段3:Pipeline设计随着开发者对音视频场景的一直理解和深刻,也提出了一些更高的要求规范。如:低时延、高清化。百度视频云通过重构的Pipeline计划,将底层能力通过管线进一步凋谢进去。 阶段4:研发范式如何让开发者更高效的利用这些管线?百度视频云也提供了一些研发范式。通过研发范式,使得管线可编程。除此之外,也提供一些简略利用的组件,可能让开发者更疾速、更高效的将凋谢能力与业务相结合。 阶段5:SDKEngine目前,SDKEngine也还在继续技术演进,次要是钻研通用引擎技术的落地,以更好满足跨平台、跨终端的音视频需要。 一站式解决方案介绍 一站式的解决方案,是以本身业务倒退为出发点,将业务依照肯定模块进行划分,并以模块化形式进行对外输入。 从上图能够看到,在最早的一站式解决方案中,会提供十分多的组件与模块。比方:录制模块、直播模块、互动模块、特效模块等,并且这些模块之间存在肯定的依赖关系。这种计划对于想疾速接入音视频场景的开发者来说是非常的高效,可能帮忙开发者从0到1疾速建设音视频场景,并提供轻量级、一站式的接口解决方案。 但事实上,客户侧的需要也在一直地发生变化。如:业务须要做推流或者一些更底层地调试以及取得底层能力的凋谢服务,这须要客户通过提工单的形式告知解决方案厂商,而厂商又须要评估、迭代,将这些能力逐渐的凋谢,这对开发者的体验并不是很敌对。因而,接口与业务解耦是引擎的下一步倒退方向。 Pipeline设计方案介绍Pipeline设计,站在交融的视角,以流水线的形式交融异构业务架构,整合音视频底层能力,复用音视频模块,以实时音视频引擎为基座,插件化对外输入。 从上图能够看到,Pipeline设计将之前比拟高级的业务接口剔除,并凋谢更底层的接口。以录制模块为例:将录制模块中,与业务相干的逻辑进行抽离,而提供像Capture这样的采集组件。通过Pipeline的设计,逐渐的把底层能力逐步凋谢进去。 然而在凋谢过程当中,如能可能让开发者更好的应用底层技术?以及如何在Pipeline上做一些更加灵便的定制?这催生了咱们新的终端引擎。 研发范式计划介绍针对开发者在Pipeline设计方案上的一些应用问题, 咱们期待终端引擎具备可编程、可自制的能力。所以,百度视频云以企业级架构为出发点,联合平台中间件和业务低代码为设计思维,对外输入能力。在之前的设计中,终端引擎都是对接APP,而研发范式计划里,对接的是开发者。这其实是一个设计理念的降级:将SDKEngine泛化为研发范式,开发者能够依据本身状况,按需应用或进行二次开发。 在利用层面 ,将常见的组件进行封装,如:相机组件、连麦组件、推流组件等,开发者可能疾速、插拔式地应用这些组件。在平台两头层面,实现了架构层面的治理。针对不同的音视频场景,能够通过构建计划、灵便自动化地打包相应的产品能力。 与此同时,底层的引擎能力也在逐步地凋谢进去,如:针对弱网的优化、传输能力等。 03 视频云音视频终端引擎面向企业级架构思考在上一章介绍了视频云音视频终端引擎的倒退历程,在整个过程中也得出了一些教训。以下是针对实际得出的一些教训: 去中心化的设计理念 背景:音视频场景越来越简单,业余水平也越来越高,随着音视频开发者逐步倒退,以业务为驱动的传统设计理念无奈满足发者对新场景的一些场景的定义。 去中心化的含意: 以业务为核心转变为以服务为前提这就意味着,云厂商要站在开发者的角度,去扫视终端引擎的倒退。该如何提供哪些能力?每个能力又该如何进行自我演进?这是一个特地好的反馈机制。 关闭架构设计转变为协同共赢如后面章节提到的研发范式这种解决方案,它实际上是将更多的接口与底层能力凋谢给开发者。这也是心愿可能和开发者们更好的协同,并更好的服务一些新的场景。 去中心化的设计理念: 繁多责任法令:将业务场景模块化。开闭法令:即高度自治,不影响其余模块。模块品质通过厂商严格的内部测试,解决开发者的后顾之忧,并且每个模块是可插拔的 ,一旦呈现问题,能够疾速剔除。 接口可替换:接口设计兼容并蓄。目前音视频辨认场景的复杂程度远超云厂商的设想,开发者对模块或者说接口的需要是个性化的。这就须要音视频终端引擎的模块、接口是能够独立输入的,并且设计兼容并蓄,以缩小开发者在应用过程中的一些累赘。 接口隔离:接口易于了解。依赖反转:面向接口编程,易用。即:要求接口是好上手,可能疾速应用的,甚至在二次开发和进一步封装的时候都是没有任何累赘的。被集成到可编程历经音视频终端引擎的倒退,咱们认为,SDK可集成是根本能力,具备可编程的能力才可能更好服务于开发者。这样可能将客户侧业务与终端引擎解耦,提供规范组件,反对可编程的范式开发。 如上图示例:原有的直播Demo,在设计层面会提供很多简单的UI与业务逻辑,而在代码层面,会蕴含很多业务的SDK,这种设计接入简略,然而能力有余,无奈拆分细化场景,影响开发者对SDK产品的辨识度。 通过B端设计与业务重构,将原有的直播Demo拆分为几个业务场景:规范直播场景、互动直播场景、低延时直播场景等,通过研发范式,将终端引擎能力释放出来。并且每个模块之间的内聚性强,节俭开发者的应用老本。 03 关键技术组件介绍数据管线组件介绍数据传递由数据管线负责,它可能让各个组件之间的数据传递实现高齐全解耦。以上图的直播推流场景为例,介绍数据管线是如何实现数据传递的高齐全解耦。 直播推流场景依照较粗的分类维度,可大抵分为以下几类:相机类、美颜类、推流类。相机类会应用到一些底层组件,比方:采集组件(开启摄像头、麦克风等),采集组件会将数据通过接口回调的模式传送给相机类,那么相机类的数据又如何传输给美颜类或者其余类呢? ...

September 30, 2021 · 1 min · jiezi

关于音视频:音频和视频流最佳选择SRT-协议解析及报文识别

咱们所晓得 SRT 是由 Haivision 和 Wowza 开发的开源视频流协定。很多人会认为在不久的未来,它被是 RTMP 的替代品。因为 RTMP 协定安全性稍低,提早绝对较高 ,而绝对于 SRT 协定反对高质量、稳定性、亚秒级提早、弱小的编解码器反对。SRT 被许多行业专家认为是视频流的新协定。SRT 到底是什么? 什么是 SRT? 安全可靠传输 (SRT) 是一种开源数据传输协定。SRT 应用用户数据报协定 (UDP),旨在通过公共互联网发送高质量视频,因而该协定是音频和视频流的最佳抉择。 在许多次要的开源技术 Wireshare、FFMpeg 中,利用了 SRT 安全可靠传输协定。 SRT 的利用在哪些畛域? SRT 协定次要的利用在直播、多流、视频编码、网关等畛域。在技术方面,它提供相似于传输控制协议 (TCP) 的牢靠传输。 然而,应用 UDP 协定作为底层传输层。 SRT 还反对低提早(默认为 120 毫秒)的数据包复原和应用高级加密规范 (AES) 的加密。 简而言之,通过 SRT,端到端流平安、视频弹性和基于网络条件的实时动静端点调整成为可能。 高质量视频传输 SRT 能够更轻松地通过互联网协议 (IP) 以低端到端提早进行流式传输。截至目前,低提早流媒体的协定偏好很少。 这是因为通过公共互联网流式传输可能会造成数据包失落和抖动等阻碍。 SRT 提供解决此问题的办法。 此外,该协定还包含避免数据包失落、抖动和带宽稳定的爱护。这意味着如果网络情况不稳固,您的流可能会进行。但它简直能够立刻从这种丢包中复原,您的观众在观看时简直不会留神到任何问题。 其余有益于直播的性能包含: 1、 基于工夫戳的数据包传输,通过源工夫传输实现更好的提早管制 2、 管制发送者的速度 3、 避免丢包未及时复原造成丢包 4、数据包重传的定期 NAK 报告SRT 如何更好的爱护你的视频流 如果您应用 SRT 协定流式传输视频,您必定会受害于它的劣势。 该协定爱护您的视频流,并确保所有数据在发送时都通过加密。 它还打消了非凡互联网连贯的累赘,因为该协定可保障您交付的视频内容的品质。 ...

September 29, 2021 · 4 min · jiezi

关于音视频:音视频同步RTCP-协议解析及代码实现

RTCP 是实时控制协定(Real-Time Control Protocol)的缩写。RTCP 由 RFC 3550 定义(取代作废的 RFC 1889)。 实时传输协定(RTP)和实时控制协定(RTCP)联合应用,能够监督大型多播网络的数据传递。RTP 承载媒体流,而 RTCP 用于监督传输统计信息和服务质量。监督使接收器可能检测是否有任何丢包并弥补任何提早抖动。 两种协定都独立于根底传输层协定和网络层协定工作。RTP 标头中的信息通知接收器如何重建数据,并形容编解码器比特流的打包形式。 上面咱们重点解说 RTCP 性能、RTCP 信息包等。最初 RTCP 协定解析实现。 RTCP 有哪些性能 1、RTCP 次要性能是提供无关品质的反馈数据散发。这是 RTP 角色不可或缺的一部分,传输协定,与流量和拥塞无关其余传输协定的管制性能。 2、RTCP 带有 RTP 的持久性传输级别标识符源称为标准名称或 CNAME。自从如果发现抵触或程序重新启动,接管方要求 CNAME 跟踪每个参与者。 接收者也可能要求 CNAME 将来自给定参与者的多个数据流关联到汇合中相干 RTP 会话的数量,例如同步音频和视频。媒体间同步还须要 NTP 和 RTP 数据发送方在 RTCP 数据包中蕴含的工夫戳。 3、前两个性能要求所有参与者发送 RTCP 数据包,因而必须管制速率以使 RTP 可能扩充到大量参与者。通过让每个参与者将其管制包发送给所有其他人,每个人都能够独立察看参与者的数量。 4、这项性能对于参加者能够任意进入和来到的涣散会话过程非常有用,参加者能够自在进入或来到,没有成员管制或参数协调。 性能 1-3 应该在所有环境中应用,尤其是在 IP 多播环境。RTP 应用程序设计师应防止只能在单播模式下工作且无奈扩大到的机制更大的数字。RTCP 的传输能够独自管制对于发送者和接收者,实用于例如单向链接,而接收者没有反馈可能的。 RTCP 协定的端口 RTSP 通常应用 RTP 协定来传送实时流,RTP 个别应用偶数端口,而 RTCP 应用相邻的奇数端口,即 RTP 端口号+1。 ...

September 27, 2021 · 9 min · jiezi

关于音视频:智感超清之HDR技术落地实践

本文由百度智能云-视频云音视频解决技术架构师——邢怀飞,在百度开发者沙龙线上分享的演讲内容整顿而成。内容从百度智能视频云的外围竞争力:“智感超清”登程,梳理了智能视频云相干的产品概念和技术。在具体介绍了HDR技术的概念根底上,联合相干“智感超清”能力,重点分享了HDR技术的利用实际。文/ 邢怀飞整顿/ 百度开发者核心视频回放:https://developer.baidu.com/l... 本次分享的主题是:智感超清之HDR利用实际。内容次要分为以下三个局部: 智能视频云3.0 & 智感超清介绍HDR技术概念解析“智感超清” HDR技术利用实际01百度智能视频云3.0&智感超清介绍百度智能视频云3.0介绍上图就是百度智能视频云3.0的全景图。能够用三句话概括: 第一,云智一体化即百度目前所有的视频云产品都实现了智能化。能够看到,图中标注的局部,“智感超清视频解决”的外围能力就包含了:智能编码、智能解决、智能抽帧、版权保护。其中,“智感超清”是视频解决产品的一个外围竞争力品牌。 第二,服务平台化联合底层的云智一体的能力,咱们搭建了两个平台:视频创作散发平台,视联网感知平台。其中,创作散发平台面向泛媒体和泛互联网场景,能够提供端到端一站式的视频服务。而视联网感知平台,面向传统监控产业,对视频端设施和泛视频数据流进行对立接入、剖析和治理。 第三,利用场景化联合具体的利用场景,百度智能视频云在泛互联网、泛媒体和泛产业方向提供了定制化的智能视频计划笼罩互动娱乐、内容生产、智能剖析、近程实时通信、生产治理、平安治理等场景。 “智感超清”MCP视频解决产品以上是智感超清 MCP视频解决产品的一个性能框架图。上面简略介绍一下每一层的构造与内容。 接入层:与其余云上产品相似,MCP视频解决产品提供两个次要入口:Console、API&SDK。用户能够通过控制台(Console)进入并进行相应的配置。而对于B端的客户,更能够灵便地采纳API/SDK的形式对产品进行拜访。 基本功能层:包含根底的云上转码的性能,也包含根本的视频剪辑/拼接/截图/字幕叠加等附件的性能。云上转码能够把用户上传的视频进行一个全格局、全协定的转换,以满足于不同客户场景下、不同网络状况、不同终端的适配,并能够灵便的做多码流切换。 智能视频解决层:这部分是“智感超清”整个产品外围打造的能力。形象出以下三个层面介绍: 第一:智能画质晋升通过AI的伎俩或其余传统的伎俩对输出的视频进行预处理,而后再进行转码解决,会带来比远视频更好的视觉体验。其中,智能HDR转换,也是和明天分享强相干的技术。第二: 智能老片修复之所以把这个门类独自进去,是因为针对这些老片,咱们须要有特定的技术进行修复,以达到降级的用户体验。具体性能包含:划痕去除,噪点去除和智能上色。第三: 智能视频编辑这一部分是根本的视频编辑能力。包含智能字幕、智能去黑边、智能去抖动等。以上三个功能模块形成了智能视频解决的外围能力。 智能视频编码:这一层是比拟底层的视频编码能力介绍 。次要包含:内容指定编码、ROI编码、4k/8k编码 、还包含百度自研的BD265编码器等。 介绍完产品框架图,咱们再介绍一下智感超清的外围竞争力在技术上如何实现。 第一局部是智能视频解决。智能视频解决的外围指标是晋升画质 。它可能通过视频预处理的形式使得在视频的分辨率、帧率、色深、色域等各个方面都能有一个较大晋升。 其中比拟外围的能力包含:SDR2HDR、超分、插帧。 在超分和插帧上都是基于AI模型。目前,在超分模型上,曾经研发了视频级别的一个超分模型;在开源数据集上,曾经达到了SOTA;在插帧的算法上,也有自研的算法,能够实现任意帧的一个插帧。 在智能老片修复上,百度也和其余的单位单干,构建了一个残缺的数据集。比拟典型的场景如:胶片上老片的物理伤害,包含其它磁带的一些伤害,“智感超清”产品通过对图像画质进行多维解决,可能在不减少视频带宽老本的状况下,实现画面质量的大幅晋升,打造视频的“极质”体验。 第二局部是智能视频编码。智能视频编码方面,曾经研发上线了AI驱动自适应的编码。该模型能够依据视频自身内容分析,预测出最优的视频码率与分辨率,并可能与ABR协定联合,生成一组最优的编码配置。与此同时,构建了一个数百万场景级别的数据集,将VMAF当成视频品质评分的一个指标。 不仅如此,百度还自研了BD265编码器,开发了60多种算法,并思考主观驱动的算法去晋升视频的画质并节俭码率。比照开源编码器,BD265编码器晋升了30%的码率,速度上也晋升了2~4倍。该编码器加入了去年的MSU大赛,在VMAF上也达到了top2的程度。这个是咱们后面对智能视频解决和编码的一个简略介绍。 通过后面的简略介绍,置信大家对智能视频云有一个根本的意识,并对“智感超清”产品有一个初步的理解。在下一章节,将给大家重点介绍HDR相干的技术。 02HDR技术概念解析什么是HDR HDR的特点能够用三个“更”字概括。 更高的亮度范畴绝对于 SDR来说,HDR能够达到10000nits的最高亮度。这使得它可能更好地展现明暗比照,在亮度方面,更加贴近人眼的对物理世界的感官认知。(能够参考上图HDR和SDR的成果比照)更广的色调范畴上图左下角示例,是一个CIE 1931色调空间的表白。传统的709畛域(即:高清),可能笼罩35.9%的色调范畴,而到了2020畛域(即:超高清),曾经可能笼罩75.8%的色调范畴。那么,如何去表白这种更宽的色调范畴呢?须要咱们更高的比特也就是更高的位深去示意。 这也对应了HDR的第三个个性: 更深的色深(位深)基本上hdr都是在10比特,更高的要达到12比特能力达到。以上是咱们对HDR成果的一个简略介绍。HDR端到端系统流程之所以想介绍这个流程,是因为HDR它不是一个单点的技术概念,它涵盖了从视频的拍摄、制作 、视频编码、解码、播放、传输等一系列流程。须要整个HDR技术生态上的企业相互配合,能力实现整个HDR端到端的零碎。下图形象的展现了整个零碎流程:视频录制(光电转换)→前期加工(产生元数据)→获取HDR视频及相干的内容元数据→压缩传输→解码→显示器显示播放(电光转换) HDR技术相干概念光电/电光传输曲线将自然界中实在场景转换为屏幕上显示进去的图像,须要通过两个次要步骤:通过摄影设施,将外界光信息转换为图像信息存储。实质上存储为数字信号。通过显示设施,将图像信息转换为屏幕输入的光信息。整个过程中,信息流要通过两个重要的非线性映射,能力造成咱们在显示设施上看到的图像。这两个重要的非线性映射过程,咱们又称光电/电光传输曲线。上面介绍三种常见的光电/电光传输曲线 Gamma曲线是一种在传统的SDR显示设施上被宽泛应用的转换曲线。对应的规范是:BT.1886,峰值亮度仅为100nits。随着显示设施亮度范畴的晋升、图像编码bit depth的晋升,使得传统Gamma校对不再实用HDR的光电转换过程。PQ曲线由杜比实验室依据Barten的人眼模型提出的电光转换曲线。峰值亮度能够达到:10000nits。长处:可能提供更高的亮度范畴。HLG曲线由BBC和NHK联结提出的光电转换曲线。长处:兼容SDR的显示和播放。在广电畛域被广泛应用。HDR元数据定义:形容视频或图像处理过程中的要害信息/特色。产生于视频的制作阶段,次要蕴含色调和亮度两大方面信息。分类:按形成构造上分类,可分为动态元数据和动静元数据。 动态元数据:视频中采纳繁多的元数据去管制每一帧的色调和细节,元数据并不会发生变化。易造成某些大动静场景的画面暗部或者高亮细节失落。动静元数据:视频中的采纳变动的元数据去管制每一帧的色调和细节。通过动静元数据,咱们还能够依据用户的显示状况,利用tone-mapping (色调映射)的算法进行更多的适配。HDR常见格局后面也提到,HDR不是一个单点的技术概念,而是一个端到端的生态。从上述图中也能够看到,HDR的格局生态非常的简单,正是因为此,HDR的规范有些割裂,并不像视频编码一样那么清晰。若依照光电/电光传输曲线的品种来划分,能够分为以下几个大的规范类型:HDR10:由美国CT组织牵头的一个凋谢规范。齐全开源收费。HLG:是由BBC和NHK联合开发的高动静范畴HDR的一个规范。HLG不须要元数据,能后向兼容SDR。HDR10+:为抗衡DolbyVision, 由三星推出的一个局部收费的规范。采纳的是动静元数据。DolbyVision:Dolby Vision应用根本层+加强层来实现向下的兼容性。并应用动静元数据来形容所有场景。但它是一个免费规范,受权体系较为简单。HDR Vivid:是国产的一个规范。在现有传输曲线和色调空间规范的根底上,减少动静元数据的形容,开源收费且兼容性好。03“智感超清”HDR技术利用实际典型超高清HDR利用需要 随着5G通信的倒退,给视频行业带来全新的改革,对应的终端能力也越来越强,互联网超高清利用空前暴发,这对超高清视频的要求也越来越高。通常,咱们所说的超高清视频包含以下六因素: 高分辨率高帧率色深解析宽色域高动静范畴全景声音频这其中,4K、HDR等技术贯通整个从采集、制作、出现等整个端到端的流程。上面看一下须要如何的技术储备,能力实现如此端到端的流程? HDR解决流程与需要剖析 内容生产:用户拍摄HDR视频上传到云端。在这一阶段,平台须要具备以下HDR的解决能力: HDR视频云端编辑能力SDR素材适配HDR中间层(Mezz)文件的编码元数据的生成元数据的透传存储(压缩)/解决(传输)阶段在HDR视频编码和解决阶段,须要以下过程: HDR转SDR。 这波及到重要的色调映射过程。多种输出格局主动适配。SDR转HDR。 能够通过AI的形式,将SDR转换为HDR。HDR格局互转能力。HDR的格局多样,可能反对各种HDR格局互转非常重要,如HDR10转HLG。HDR元数据的写入、透传。在原始HDR视频根底上,是否在码率压缩后写入,这也对云端能力提出了要求。HDR显示:在视频播放阶段,须要肯定的策略在端上做相应的适配。具体来说,须要实现: HDR终端视频播放SDR终端视频播放端上主动适配在接下来的章节,会详细分析各项技术的实现过程。HDR转SDRHDR转SDR的过程实际上是一个色调映射的过程。(Tone Mapping Operator)HDR和SDR视频的亮度空间和色调范畴都差异很大,这其中的转换过程较为简单。艰深了解,色调映射就是一个将HDR的图像或者视频,转换为SDR的图像,并在SDR显示设施正确显示的技术。以下是典型色调映射解决的流程: 预处理通过预处理,将图像的亮度信息转换为log域。图像合成通过图像的保边滤波器,将图像分解成根底层和细节层。亮度信息提取将提取出的根底层亮度信息通过不同的色调曲线进行压缩,并将压缩后的亮度信息加在细节层上。后置解决通过后置解决,进行色彩校对,失去SDR图像。在色调映射过程中,最重要的是如何抉择不同的实现算法。这须要结合实际的利用场景。SDR转HDRSDR转HDR也是一个十分复杂的过程,不仅仅是变换色彩空间和动静范畴,更须要思考暗部细节加强与过曝细节的修复、对比度的晋升、色调放弃不变、色调加强解决以达到HDR的要求以及通过算法实现对噪声的管制。在亮度方面:心愿通过SDR视频中残留的,适度曝光和曝光有余区域的信息,尽可能地复原这些区域内失落的细节。在色调方面:通过SDR视频中受限的色调,预计出原始场景的色调,让复原出的HDR视频的色调尽可能地靠近原始场景中丰盛而实在的色调。 上图能够看到传统办法对SDR转HDR的过程,次要是通过线性转化的形式,对过曝/欠曝的区域进行重建。目前AI的办法,在超分和加强畛域用的十分多,因为它应用的是非线性的表白,个别认为通过AI的办法能够实现SDR转HDR的更好成果。 基于AI的端到端SDR转HDR计划 特点: 采纳全局/部分信息交融的形式。采纳Residual Connection残差学习。Squeeze-Excitation,channer维度自注意力算法加持。超高清预测分辨的速度快。以下是基于AI的SDR到HDR的成果展现: 能够看到,基于AI的SDR到HDR的转换,在晋升动静范畴的同时,还补充了曝光有余区域(暗影)的局部细节。整个画面细节更丰盛,档次更明显,整体的色调饱和度上也有显著的晋升。在AI模型的训练过程中,数据的积攒非常重要。这也是该计划在后续须要优化的中央。 HDR格局之间的转换HDR的格局多样,所以可能反对HDR格局之间互相转换十分必要。与转码相似,HDR格局上也须要做一个对立散发。要了解HDR格局互相转换的这个过程,须要对PQ零碎模型和HLG零碎模型有一个粗浅的了解。 PQ零碎模型环境光通过光光转换曲线、逆电光转换曲线,变换成PQ的电信号。在显示阶段,通过电光转换曲线,变成显示光。HLG零碎模型环境光通过电光转换曲线,变换成hlg的电信号。在显示阶段,通过逆电光转换曲线、光光转换曲线,变成显示光。HLG零碎模型从流程上看,根本与PQ零碎模型是相同的。HEVC HDR反对这部分以HEVC为例,重点介绍编码在HDR上是如何承载的。HEVC对元数据的承载蕴含两个局部的重要信息。 VUI信息 ...

September 26, 2021 · 1 min · jiezi

关于音视频:经验分享RTC-技术系列之视频编解码

要理解什么是视频编解码,首先咱们须要理解什么是视频。 视频归根结底是一系列间断的图像帧,当这些图像以肯定速率播放时,人眼就会判断其是间断流动的,这样就形成了视频。 那为什么要进行视频编解码呢,因为视频信号数字化后数据量微小,如果以这样的数据量进行网络传输或者存储时,会占用大量的带宽和存储空间,造成节约。已以后支流的 1080P 分辨率,一秒 30 帧的视频举例 1080P 图像的高和宽别离为 1080 和 1920,每个像素用三原色 RGB 示意(即每个像素三个字节),因而每帧图像的数据量为 1080x1920x3x8=49766400,每秒 30 帧,则须要乘以 30,49766400x30 = 1,492,992,000bps。因而视频编解码技术因而而诞生。 为什么视频能够压缩呢,咱们分两个方面看这个问题: 1 在一副图像中,往往有相近的色彩区域,这样就蕴含了大量的冗余信息,能够基于变动编码和量化编码进行冗余信息处理,达到压缩的可能。 2 两幅图像之间,必定也存在大量雷同以及类似的局部,因而产生了静止弥补及静止预计来形容静止矢量来进行图像间冗余信息压缩的可能。 基于图像内预测编码和图像间预测编码原理,诞生了泛滥的视频编解码。 H.26X 系列,从 H.261,H.263,到以后支流的 H.264,及 H.265,以后最新制订规范的 H.266;H.26X 系列的倒退主旨为应用技术优化压缩数据量不可能达到更好的视频品质;像 H.265 旨仅需原先的一半带宽即可播放雷同品质的视频。它与 H.264 有着相相似的算法架构,并同时对一些相干技术加以改进而大幅提高视频品质。 Mpeg 系列,Mpeg1,Mpeg2,Mpeg4(Mpeg4 之后与 H.264 交融); VP 系列,VP8,VP9;VP 系列是 Google 自研并开源的编解码系列,Google 创立 VP 系列编解码的起因也是 H.264 须要专利费用,即如果 WebRTC 应用 H.264,则须要按浏览器领取相干的专利费用(当然因为 H.264 宽泛支持性,次要起因还是 cisco 开源了 OpenH64),VP8 即对标 H.264,除了在 WebRTC 畛域,其知名度和反对度则绝对无限; VP9 则对标 H.265,VP9 的指标之一是在保障雷同品质的状况下绝对于 VP8 能够缩小 50%左右的码率,换句话说,雷同的码率,VP9 能比 VP8 画质有非常明显的进步; ...

September 24, 2021 · 1 min · jiezi

关于音视频:音视频专题音频质量评估方法那些事

明天加入了声网 Agora 的《实时语音品质监控零碎的过来、当初与将来》,联合之前工作时音频解决的一些教训,分享一些本人的了解。 音频(泛指人能听到的自然界的所有声音,人耳能听到声音的频谱范畴个别为 20~20000HZ)和语音 (语音是指人谈话的声音,人谈话的声音频谱能量范畴大部分散布在 300~3400HZ)两者是不同的,能够看出人是能够听到比人谈话更广范畴的声音的;这就是人能够听到像乐器,自然界,尖鸣声这些声音,然而人并不能收回来。 为什么要做品质评估,起因有几个方面,比方大家除了面对面交换,在通话,刷视频,听音乐等等流动中的音频是通过了编解码压缩解决的,是为了便于更小代价的传输和存储;像原始声音中掺杂噪声的去除,原始谈话声音的加强解决等;能够看出不论是编解码解决还是其余语音解决,目标都是让人听起来更难受,因而品质评估办法就是评估在对于声音进行解决后的人听起来的感触度状况。 音频评估办法分为主观评估和主观评估。 主观评估其实就是人凭借听觉感触对语音进行打分,常见的有 MOS、CMOS 和 ABX Test;像 AB TEST 在我晚期的工作中常常应用到,比方对语音加强算法做了小的优化,想得到理论听觉的感触改善状况,就会把原始算法和优化后算法解决后的语音进行编组,让小伙伴们帮忙测试打分,以此判断是变优还是变差。国际电信联盟(ITU)将语音品质的主观评估办法做了标准化解决,代号为 ITU-T P.800.1。其中收听品质的相对等级评分(Absolute Category Rating, ACR) 是目前比拟宽泛采纳的一种主观评估办法。参加评测的人员对语音整体品质进行打分,分值范畴为 1-5 分,分数越大示意语音品质最好。这种 MOS 值分数起初也利用于主观品质评估。个别 MOS 应为 4 或者更高的,会被认为是比拟好的语音品质,一旦 MOS 低于 3.6,则这个语音品质根本不太能承受。 主观评估则次要是应用算法代替人打分的工作,通过算法来评测声音的品质。在主观评估中又分为有参考评估和无参考评估。 有参考评估(intrusive method)顾名思义,须要声音源素材进行比照,因而这种办法只能用在线下解决上,对于实时通话解决是不可能做到的;常见的有像 ITU-T P.861(MNB), ITU-T P.862(PESQ)[2], ITU-T P.863(POLQA)[3], STOI[4], BSSEval[5],无参考评估(non intrusive method)则不须要声音源素材,常见的有 ITU-T P.563[6], ANIQUE+[7],ITU-T G.107(E-Model)[8],基于 AI 深度学习的 AutoMOS[9], QualityNet[10], NISQA[11], MOSNet[12]等等上面表中为支流语音编解码 MOS 值测试评分(来自 Opus 官网,起初又进去了 MOS9,即最高分为 9 分 这里重点介绍下 PESQ 和 POLQA PESQ 属于有参考的主观评估计划,将两个音频信号作为输出,其中一个由 itu 组织提供,另一个输出为通过被测 voip 零碎解决后的输入信号。Pesq 算法通过对输出的两个信号提取时频域或变换域特征参数的差别,再将特征参数差别经神经网络模型映射失去主观的音质分值。PESQ 分值其实就是对 MOS 值的一个映射。 ...

September 22, 2021 · 1 min · jiezi

关于音视频:Javacv-音视频小工具-下载抖音视频

一、前言大家好,俗话说的好,学习新的常识后要学以致用,在学习音视频的过程中,你有没有疑难,不晓得音视频能够用来做什么。上面举几个例子,比拟耳熟能详,被吹到风口的一些场景有:AI 视觉计算, AI 人脸识别. 细化到一些小的畛域,如当初直播技术,摄像头监控拉流;其余还有抖音中的美颜,滤镜,其背地是应用的音视频畛域的数字化妆技术。由此可见,音视频技术利用曾经利用于咱们生存的方方面面。 二、开发背景想写这篇文章的目标是因为,我有个敌人平时喜爱刷抖音,就常常有一些视频被作者设置成了不可下载保留,敌人下次想再看的话就找不到了。 还有敌人想下载暗恋的妹纸的作品。所以就把苦闷通知我了,作为敌人当然有任务帮忙他走出窘境啦,终于,Two thousand years later 的明天,这个小工具终于问世,因为工夫起因,来不及写前端页面了,前面有须要的同学能够关注或者私信我,咱们一起学习,另外,写本文的目标纯正是以学习为主,如不小心被不法分子滥用以盈利为目标,与自己无关,请宽广道友踊跃爱护学习环境,记得不要牵累我。 三、核心思想其实外围步骤就两步 1、依据抖音上复制的分享链接获取到抖音的实在地址,须要应用网络编程技术解析到视频的实在地址。 2、而后应用 ffmpeg 解码网络视频流,保留到本地。 四、次要技术点1、次要应用 Java 与 一些网络调用的常识,例如 Restemplate 的应用,Restemplate 是 spring web 中的一个模板办法类,这里次要用到了他的两个办法(headForHeaders, exchange),当然也能够用其余的工具类或者本人去实现网络近程调用。 2、JSON 解析应用 fastjson,版本号随便,个别都能够兼容。 3、StringUtils 是应用 commons.lang3 包上面中的工具类,不要导错包啦。 4、ffmpeg 拉流应用的第三方依赖是 javacv,版本 1.4.3 版本。如需具体援用依赖,关注或者私信我。 5、如果你对于 ffmpeg 基本概念,音视频基本概念,如视频帧, 音频帧,码率等基本知识不是十分分明,这里我只说技术的利用,对于原理的解说,不做过多赘述,网上一搜一大堆,有趣味能够本人去理解以下。 6、应用 javacv 中的 FFmpegFrameGrabber 帧抓取器来获取音/视频帧,用这个抓取器,能够省略原生的 API 调用的一堆简单操作,例如关上视频流,查找解码器,判断音频帧和视频帧。 来自网上的一段介绍/概括 FFmpegFrameGrabber 用于采集/抓取视频图像和音频采样。封装了检索流信息,主动猜想视频解码格局,音视频解码等具体 API,并把解码完的像素数据(可配置像素格局)或音频数据保留到 Frame 中返回等性能。7、还能够应用 ffmpeg 命令行的形式进行下载。命令如下: ffmpeg -i https://xxx.mp4 -c copy -f flv 艾北.flv然而这种形式须要部署机装置 ffmpeg,所以临时不思考这种形式了。 8、应用 javacv 中的 FrameRecorder 录制器来把曾经解码的图像像素编码成对应的编码和格局推流出去,这里保留到本地就是推流到本地文件。 ...

September 17, 2021 · 2 min · jiezi

关于音视频:音视频编解码流程与如何使用-FFMPEG-命令进行音视频处理

一、前言FFMPEG 是特地弱小的专门用于解决音视频的开源库。你既能够应用它的 API 对音视频进行解决,也能够应用它提供的工具,如 ffmpeg, ffplay, ffprobe,来编辑你的音视频文件。 本文将简要介绍一下 FFMPEG 库的根本目录构造及其性能,而后具体介绍一下咱们在日常工作中,如何应用 ffmpeg 提供的工具来解决音视频文件。 二、FFMPEG 目录及作用libavcodec: 提供了一系列编码器的实现。 libavformat: 实现在流协定,容器格局及其本 IO 拜访。 libavutil: 包含了 hash 器,解码器和各利工具函数。 libavfilter: 提供了各种音视频过滤器。 libavdevice: 提供了拜访捕捉设施和回放设施的接口。 libswresample: 实现了混音和重采样。 libswscale: 实现了色调转换和缩放工能。 三、FFMPEG 基本概念在解说 FFMPEG 命令之前,咱们先要介绍一些音视频格局的基要概念。 (1) 音/视频流在音视频畛域,咱们把一路音/视频称为一路流。如咱们小时候常常应用 VCD 看港片,在里边能够抉择粤语或国语声音,其实就是 CD 视频文件中寄存了两路音频流,用户能够抉择其中一路进行播放。(2) 容器咱们个别把 MP4、 FLV、MOV 等文件格式称之为容器。也就是在这些罕用格式文件中,能够寄存多路音视频文件。以 MP4 为例,就能够寄存一路视频流,多路音频流,多路字幕流。(3) channelchannel 是音频中的概念,称之为声道。在一路音频流中,能够有单声道,双声道或立体声。四、FFMPEG 性能分类咱们按应用目标能够将 FFMPEG 命令分成以下几类: 根本信息查问命令录制合成/复用解决原始数据滤镜切割与合并图/视互转直播相干除了 FFMPEG 的根本信息查问命令外,其它命令都按下图所示的流程解决音视频。 而后将编码的数据包传送给解码器(除非为数据流抉择了流拷贝,请参阅进一步形容)。 解码器产生未压缩的帧(原始视频/ PCM 音频/ ...),能够通过滤波进一步解决(见下一节)。 在过滤之后,帧被传递到编码器,编码器并输入编码的数据包。 最初,这些传递给复用器,将编码的数据包写入输入文件。 默认状况下,ffmpeg 只蕴含输出文件中每种类型(视频,音频,字幕)的一个流,并将其增加到每个输入文件中。 它依据以下规范筛选每一个的“最佳”:对于视频,它是具备最高分辨率的流,对于音频,它是具备最多 channel 的流,对于字幕,是第一个字幕流。 在雷同类型的几个流相等的状况下,抉择具备最低索引的流。 ...

September 15, 2021 · 5 min · jiezi

关于音视频:人类视觉神经科学助力音视频产业革命-弱网下的极限实时通信

一、什么是弱网?1.1 弱网概念弱网从字面意思看就是网络比拟弱, 咱们通称为信号差, 网速慢, 随着挪动互联网炽热倒退的这些年, 大量用户会在地铁, 隧道, 电梯和车库等非凡场景下应用挪动端 APP 。这些场景下, 网络会呈现提早、中断、抖动、超时等状况。 1.2 网络状态网络状态蕴含有线连贯, 2G/3G/4G/5G/Edge/Wifi 等多种网络连接模式, 从测试的角度说, 也蕴含断网, 网络故障等状况, 对于弱网的数据定义, 不同的利用所界定的含意也是不一样且不清晰的, 一般来说低于 2G 速率的都属于弱网, 也能够将 3G 划分为弱网, 除此之外, 极低宽带 < 50kbps, 弱信号的 Wifi 等也是弱网。 1.3 钻研背景有一些非凡场景, 例如 : 森林救灾, 边防监控, 等场景, 这些场景往往关乎国家平安与生命安全, 更加须要严苛的实时通信, 然而这些场景依赖的基站往往会受到天然因素的烦扰, 例如地震等自然灾害。 二、尝试了哪些技术尝试?2.1 AI 管制在观看直播过程中听到马老师提出了一个新的概念, 人眼在感知图像的时候, 解决大略是 100B/s, 而后通过视网膜上的细胞进行拆散之后, 大略压缩了 100 倍, 而后通过一系列的细胞解决, 最初只有大概 40b/s, 并且人眼关注的区域分辨率绝对高一点, 人眼不关注的区域绝对分辨率就低一点. 并且人眼对于某些区域, 某些色彩特地的敏感, 叫做注意力机制。 传统的流控技术在进行音视频编码和传输的过程中往往无奈依据具体的网络环境抉择适宜的算法和码率管制, AI 管制模块(相当于人脑)会收集视频会话教训(人眼关注的货色), 包含视频编码器、接收端的编码状态、网络、播放状态, 依据这些特色, 反抗网络稳定, 作出编码参数的设置决策。 ...

September 13, 2021 · 1 min · jiezi

关于音视频:流媒体依托于声网的连麦解决方案

一、背景近些年,直播连麦这把火在流媒体畛域整整焚烧了 6 年。从刚开始的简略摸索,到当初的成熟全链路计划,不得不说日益增长的强烈竞争,已将让本来的蓝海畛域变成了深海互搏。在这样的大环境下,是否意味着小厂将再也没有机会追赶流媒体行业风口,以小搏大呢?答案当然不是,感激多年来的市场驱动带来的技术思维碰撞,由此诞生了一批专精通信的技术供应商。使得任何组织都可通过正当的对端方案设计,实现流媒体赋能。而声网作为这样的合作伙伴,则是其中的佼佼者。 这就是这篇文章将要谈到的内容:基于声网的对端连麦计划。 二、宏观流程在咱们正式开始前,首先须要做的就是依据连麦的参与者,和连麦的阶段,进行阶段角色划分。从整体流程上看,对于任意连麦的两端来说,本人都是主播端,而另一方都是连麦端。因而,惟一的区别不在于身份上,而在于谁先发动了连麦的申请。这会决定整个连麦从发动到接通的残缺链路流,是一个怎么的过程。 所以,咱们就有了根本的框架需要: 1.从被连麦端开始,构建建设房间、开始连麦、连麦中、完结连麦的残缺链路 2.业务层解决流程,刨除底层简单技术实现的疾速集成计划 3.高接通率健壮性,从实现角度保障申请的及时精确 依据这三则外围诉求,咱们提供如下的连麦解决方案。 图2-1 宏观流程阐明 接下来,咱们就来别离拆分来看一下。 三、阶段拆解主播启播阶段对于主播启播阶段的解决,次要是通过以后主播服务侧的特色数据,来决定该主播是否可能开启连麦直播间。为什么会就直播间是否是连麦直播间而进行辨别呢?次要还是波及到连麦直播间全链路对于各环节要求会更多一些。在这里做辨别一方面对于主播来说操作代价并不大,另一方面也能够缩小服务端对于此类直播间的记录,并利于维持更适合的预筹备策略资源池大小。 主播在申请启播时,向服务器收回的启播地址申请,会被服务器依据启播策略筛选开启直播间类型。服务器会依据判断后果,抉择是否开启具备连麦扩大能力的直播间并返回其推流地址到主播端。主播就能够以此地址进行开播推流了。 图3-1 启播阶段关键环节示意图 连麦发动阶段在主播开启直播间后,所有满足连麦要求的对端,都能够向主播发起连麦申请。连麦申请的一方有可能存在竞争。因而对于先发动申请的连麦方,在其或者主播并未因为客观原因明确否定本次连麦流动前。咱们应该通过绑定主播和连麦端的形式,来防止旁路烦扰。 当然呢,在确立连麦关系前,咱们须要对连麦方的资格进行校验。目标是为了保障,当次连麦流动的理论有效性。否则咱们对于不满足资质的连麦方调配了连麦关系,就会等于变相的抢占了对繁多直播间来说本就稀少的连麦权限。这将会带来不少的平安和治理危险。同时为了防止发动连麦端,在发动之后相当短的工夫内反悔连麦操作。咱们须要预留进去局部工夫用来提供一个“返回窗口期”,这部分的工夫策略具体阈值界定,就须要产品依据用户特色来进行数据分析决定了。 一旦连麦关系确定,那么对于连麦端来说,就须要进入“连麦期待”状态了。此时主播则会接管到连麦申请。依据主播决定批准/回绝,来决定是否须要建设连麦直播间。 如果主播抉择回绝,则以后连麦绑定关系被开释,发动连麦方会收到单推并获之失败起因,其余用户也能够从新竞争连麦。 如果主播批准,则在预筹备策略中进行预处理的资源会被间接调配给以后确立的连麦流动。并就此将原有直播间晋升为连麦直播间。服务端会开启推流地址的动静切换策略,并将关联信息返回给推流双端,以实现声网链接初始化。 图3-2 发动阶段关键环节示意图 整个连麦发动阶段对于用户来说,根本是无缝连接的。这次要通过混合推流来实现这样的操作。在主播连麦前,主播端相当于间接将本地流推送到推流服务器,由推流服务器进行后续的包含转码散发等操作。而当连麦建设后,双端推流首先通过声网服务器进行了流混合。之后通过咱们传递的主播端推流地址,将混合后的流转发给咱们本身的推流服务器。这也就相当于,用声网实现解决后的流替换了咱们原始主播的直推流,服务端只须要就此实现局部工夫戳校验同步服务,减小了切流带来的卡顿影响。 连麦过程阶段当主播和连麦方残缺建设连贯后,就进入了连麦过程阶段。这一阶段就心跳维持和推拉流来说,为了保障稳固链接和肯定的交互扩展性,应该在声网本身 IM 音讯判断外,额定维持一套独立的心跳申请。通过心跳申请,将双端工夫戳发由服务端进行连麦理论时长同步。同时,也利于服务端依据具体情况,就一些要害数据与双端进行协同。另一方面,如果不采纳强绑定机制,即推流 CDN 等相干流推送局部为非声网的第三方供应商时,咱们也须要通过心跳申请来失去并判断以后网络状态。当然,除了心跳申请这种形式外,还存在诸如控制流音讯定制等其余形式能够实现雷同的成果。这种形式保活绝对快捷不便耗费较小,不须要维持长链接,不过须要小心申请的平安解决。 图3-3 连麦过程关键环节示意图 连麦中,双端常常有一些交互流动。对于相似于打赏的操作,倡议通过直播间音讯管线来实现。这样的话能够不须要再独立保护一套自建 IM 用于双路双端的消息传递,而能够间接利用直播间现有音讯管线实现双端通信。如此不管直播间如何切换,音讯管线都是继续存在且不必重启,保障了主播和观众的体验。其实,如果没有一些非凡的定制化操作,连麦端的音讯解决和其余观众是一样的,即音讯逻辑统一。 连麦断开阶段那么什么时候连麦完结呢?这个实际上是有多种状况的。最常见的就是主播或者连麦端的被动断开,除此之外还有网络稳定断开、服务端策略断开等状况。从大体上讲能够分成两类,即被动断连和被动断连。 被动断连,指的是由参加连麦的双端中的一端或者多端,单方面或者达成统一的短线操作。 被动断连,指的是因为内部烦扰或者服务端策略影响,导致的连线终止。 对于被动断连(如:断连、费用有余、继续掉线等),咱们最好在问题产生前,有足够的策略可能进行容错解决。其目标是为了保障,在断开后直播间还可能恢复正常,而不至于因而产生健壮性问题。 图3-4 连麦断开关键环节示意图 连麦中咱们应用声网来作为了真正的推流端,声网混流服务器将混合好的数据推送到咱们自建/第三方推流服务器上,并以此散发到 CDN。当一端退出时,退出的音讯会随着视频流(声网将对应的状态音讯封装到了数据流中的关键字段上,以保障链接方画面与接管操作的端上一致性)推送到对端。对端接管到音讯后,也须要向以后占用的声网直播间发送退出房间音讯,能力使连麦房间真正变成双端无关的房间(有时存在审核需要,连麦房间内可能存在除连麦单方外的多个用户,这些用户都属于在服务端的审核机器人或着人工账号),进而能力由服务端开释房间资源偿还到资源池,或者重新分配给新场景。 当连麦完结后,主播端状况抉择是否申请服务端直播间地址更新(集体倡议执行,让服务端抉择是否更新),在获得后切换以后端推流地址为获得的地址。连麦方则敞开推流模块,重启拉流模块并从新进入被连麦的主播直播间。 就此,连麦流程结束。 四、总结相比起独立开发连麦性能的大量工作,采纳咱们介绍的混和实现的计划,既可能保障整体框架的低捆绑高兼容,又可能借助声网成熟的通信解决体系来升高危险老本。同时,与所有第三方的松耦合,也意味着咱们能随时在接入方面进行替换。 不过我置信,声网还是会判若两人的以稳固高效的网络和业余下沉的技术,来让您感叹:间接应用声网还是更加高效便捷。届时,自研连麦外加声网连麦的混合形式,也未尝不是一种优雅的的抉择。

September 10, 2021 · 1 min · jiezi

关于音视频:浅谈实时语音质量监控系统

明天小王学长跟大家谈谈实时语音品质监控零碎的前世今生, 实时语音想必大家都不生疏,微信语音聊天、视频直播,生存中的例子亘古未有。 在过来的语音通信零碎中,影响语音品质的因素有很多,包含但不仅限于延时(delay)、丢包(packet loss)、包提早变动(packet delay variation)、回声(echo)、以及因为编码造成的失真。 语音品质评估办法总的来说能够分为三种:有参考主观评估办法、主观评估办法和无参考主观评估办法。 有参考主观评估办法: 是指把原始参考音视频与失真音视频在每一个对应帧中的每一个对应像素之间进行比拟。精确的讲,这种办法失去的并不是真正的视频品质,而是失真音视频绝对于原始音视频的类似水平或保真水平。最简略的办法如均方误差 MSE 和峰值信噪比 PSNR,其利用比拟宽泛。 PESQ 语音品质作为掂量语音传输性能的一个重要指标,如何失去精确、牢靠的 QoE(体验品质)评估零碎已成为以后钻研的重点,PESQ(perceptual evaluation of speech quality,语音品质评估算法)是由 ITU 提出的基于 QoE 的语音品质评估算法,并随之成了 ITU-T P.862 规范。 PESQ 算法是以后比拟风行的语音品质评估算法,说到 P.862 规范,P.861 PSQM 是最早的规范,ITU-T P.861 也叫做 PSQM,是依据 PAQM 推倒进去的一种语音品质评估体系。目前,P.862 PESQ、PESQ-WB 是利用最宽泛的有参考评估办法,最新的有参考评估办法有 P.863 POLQA,这些都是依赖无损参考信号的。 无参考主观评估办法: 语音品质主观评估钻研自七十年代以来失去了迅速倒退,国内外学者提出了数以千计的主观评估办法。主观评估次要根据的就是原始语音信号和失真语音信号的时频域或变换域的特征参数比照。其次要是针对主观评估办法的有余,人们早就心愿有主观评估办法来评估语音设施的音质,这之后许多人陆续提出了基于主观测度的主观音质评估办法。心愿采纳这些办法不便、快捷地给出被测语音零碎的语音品质评价值,只不过评估的主体是由机器硬件或软件来实现。目前国内外采纳较多的主观评估办法有 PSQM、PAMS 和 PSQM+等办法。其中 P.563 是最驰名的窄带无参考评估办法。像 ANIQUE+这样的据作者称准确度超过有参考的 PESQ,其它的还有像 E-Model/P.1201 参数域评估办法以及 xxNet 深度学习域评估办法。 主观评估办法也有许多弊病: 有参考办法:只能用在上线前无参考办法-传统信号域:利用场景窄、鲁棒性差无参考办法-传统参数域:仅在无限弱网条件下能够放弃精度无参考办法-深度学习:利用场景和语料无限,复杂度略高 通常,咱们能够从不同方向提出各种主观语音品质评估办法,然而主观语音品质评估必须最终通过其与主观语音品质评估的相关性来确定其性能和可靠性,咱们通常通过主观和主观语音品质评估的拟合过程做出上述判断。拟合的过程是通过主观和主观语音品质评估输出不同条件下的语音主观和主观值,而后对主观和主观值进行最小二乘拟合,其中程度轴上的目标值为目标值在垂直轴上。画出语音的主客观品质评估曲线,得出主客观语音品质评估的比拟关系。人们通常应用预测的均方误差值来反映主观和主观语音品质评估的相干水平。预测的均方误差值越靠近,主观和主观语音品质评估之间的相关性越好,即,主观语音品质评估的性能越好。相同,它表明主观和主观语言品质评估之间的相关性越差,即主观语言品质评估的性能越差。 倒退到当初以线下测试的线上化为主,具备高精度、广覆盖、低复杂度、强鲁棒等特点。 品质评估足够精确笼罩绝大多数业务场景不引入过多算法复杂度和语音内容弱相干上行链路品质评估办法: 采集-AEC-NS-AGC-诊断,具备独立检测+对立检测 特点:设施采集稳定性、回声打消能力、噪声克制能力、音量调整能力 上行链路品质评估办法: 采纳编码-传输-解码-播放 举一个某实验室的例子,其验证数据绘制寰球音频品质地图的外围指标有:编解码器性能、网络品质、弱网反抗算法品质、设施播放能力。 其在多弱网、多设施、多模式的测试 case 下,该办法的打分与 POLQA 的参考打分 MAE 小于 0.1 分,MSE 小于 0.01 分,误差最大值小于 0.15 分 ...

September 6, 2021 · 1 min · jiezi

关于音视频:深入篇漫游语音识别技术带你走进语音识别技术的世界

前有今人,后有小王,大家好,我是你们爱思考的小王学长,明天咱们持续漫游语音辨认技术哈,明天内容略微业余一些,大家能够联合上一篇漫游语音辨认技术一起学习。 上篇咱们简略理解了语音辨认技术的概念、前世今生以及根本辨认原理,一会学长带着大家漫游到语音辨认技术更深(更业余)的世界里。 文章目录:(大家先预览下) 一、语音辨认根底二、信号处理过程 1、降噪解决 ①小波变换降噪法 ②谱减法 ③自适应噪声对消法 ④声音滤波器 2、预减轻 3、分帧加窗 4、端点检测三、特征提取四、语音识别方法 1、声学模型 2、语言模型 3、解码器 4、基于端到端的学习办法五、深度学习-CNN实战举例六、声网 Agora 一站式智能语音辨认计划七、语音辨认开发平台 深度学习平台 语音辨认开发平台八、语音辨认相干开源学习材料 开源数据集 开源语音辨认我的项目作者介绍一、语音辨认根底说到语音辨认,咱们应该先思考一下声音是什么呢? 通常咱们能够认为声音是在空气中流传的波,然而它不像水波那样流传波的高下变动,它流传的是空气的密度变动。比方,咱们拍手时手掌的振动将空气挤出,比照四周的大气压,空气被挤入的中央压力增高,而空气被挤出的中央则绝对压力升高;压力高的局部向手掌周围挪动,而压力低的局部则紧随其后。这种由手掌振动所引发空气密度产生周期性变动的波称为压缩波,空气中的压缩波一旦碰到鼓膜那样的薄膜,就会使其产生振动。麦克风的作用就是将这种振动以电信号的模式提取进去。上面的图大家能够参考一下 几种波形或叠加模式(点击图片可见起源) 以振动的幅度为纵轴,以工夫为横轴,就可能将声音可视化。 换句话说,声音以波的模式流传,即声波。当咱们以波的视角来了解声音时,幅度(Magnitude)、频率(Frequency)、相位(Phase)便形成了声波及其所有的叠加声波,声音的不同音高(Pitch)、音量(Loudness)、音色(Timbre) 也由这些根本单位组合而来。 世界上各种各样的声波都能够“降解”到根本波身上,傅里叶变换(Fourier Transform)的根本思维也是这样的。不同的声波有不同的频率和幅度(决定音量),人耳也有本人的承受范畴。人耳对频率的承受范畴大抵为 20 Hz 至 20 kHz,于是以人为本地将更高频率的声波定义为超声波(Ultrasound Wave)、更低频率的声波定义为次声波(Infrasound Wave), 尽管其它动物能够听到不同范畴的声音。 上一篇大家应该对 ASR 有了个初步的理解,语音辨认说白了最终是统计优化问题,给定输出序列 O={O1,...,On},寻找最可能的词序列 W={W1,...,Wm},其实就是寻找使得概率 P(W|O)最大的词序列。用贝叶斯公式示意为: 其中 P(O|W)叫做声学模型,形容的是给定词 W 时声学察看为 O 的概率;P(W)叫做语言模型,负责计算某个词序列的概率;P(O)是察看序列的概率,是固定的,所以只看分母局部即可。 语音抉择的根本单位是帧(Frame),一帧数据是由一小段语音通过 ASR 前端的声学特征提取模块产生的,整段语音就能够整顿为以帧为单位的向量组。每帧的维度固定不变,但跨度可调,以适应不同的文本单位,比方音素、字、词、句子。 大多数语音辨认的钻研都是别离求取声学和语言模型,并把很多精力放在声学模型的改良上。但起初,基于深度学习和大数据的端到端(End-to-End)办法倒退起来,能将声学和语言模型融为一体,间接计算 P(W|O)。二、信号处理过程1、降噪解决在降噪之前,我先跟大家讲讲为什么要进行降噪解决? 咱们在录制音频数据的同时,大量噪声都会掺杂进来,不同环境和情境下产生的噪声也不尽相同,噪声信号中的无规则波纹信息影响了声学信号所固有的声学个性,使得待剖析的声音信号品质降落,并且噪声对声音识别系统的辨认后果会产生重要影响。所以说,咱们在对声音信号剖析和解决之前,是肯定要进行降噪解决的。(语音的具体噪声分类:看学长这篇文章) 上面咱们来看几个降噪的罕用办法: ①小波变换降噪法小波变换降噪法简称小波降噪,个别在声音降噪中应用最多的是小波阈值降噪法,它次要是说在带噪声音信号中,无效声音信号与噪声在不同频率上有着不同的小波系数,其中无效信号能量谱体现会比拟集中,在能量谱集中的区域小波系数的绝对值会比拟大;而噪声的能量谱比拟扩散,所以其系数的绝对值比拟小。接下来,依据此特点,利用小波变换法将带噪声音信号合成到不同频率上,而后设置阈值进行差分调整,保留无效声音信号的小波系数,最初依据小波重构算法还原带噪信号中的无效信号,从而能够达到降噪的成果。 这是其基本原理,其中阈值的设定也能够分为硬阈值和软阈值法。具体波及的相干公式和计算方法大家感兴趣的能够百度或者跟我留言。以下是利用小波降噪法失去的前后比照图(在 MATLAB 环境下失去): 含噪声信号的波形 小波降噪后的波形 ②谱减法谱减法又称频谱减法降噪,是依据噪声的可加性、部分平稳性以及噪声和无效声音信号不相关性的一种声音信号降噪办法。这种降噪办法不会波及到参考信号,其次要思维就是带噪声音信号是无效信号与噪声的叠加,那么带噪信号的功率也是相当于无效声音信号的功率和噪声功率的叠加,利用计算失去“静音”片段(信号中不含有无效信号,只含有零碎噪声或者环境噪声)中噪声的频谱估计值来等值替换无效声音信号存在期间所含噪声的频谱,最初带噪声音信号的频谱与噪声的频谱估计值相减,就能够失去无效声音信号频谱的估计值。 ③自适应噪声对消法自适应噪声对消法的外围组成部分是自适应算法和自适应滤波器。自适应算法能够主动调节输出滤波器的加权系数使滤波器达到最优滤波成果,所以自适应噪声对消法的要害是在于找到某种算法,能够实现主动调节加权系数。 自适应噪声对消法的次要思维是:除了带噪声音信号 x(t)=s(t)+n(t),假如还能够失去另外一个参考信号 r(t),而这个参考信号与噪声 n(t) 相干,然而与无效声音信号 s(t)不相干,那么就能够依据 Widrow 算法(一种近似最速降落的神经网络算法)对消带噪声信号中的噪声,从而达到降噪的成果。 ...

September 2, 2021 · 3 min · jiezi

关于音视频:笔记分享-弱网下的极限实时视频通信

明天给大家分享一下 InfoQ 平台公开课——弱网下的极限实时视频通信,对于实时视频通信的极限摸索,主讲人是南京大学的马展传授。 一、课题背景首先说下课题的背景,平时手机、电脑等网络设备接管信息的准确性和及时性都与实时通信无关,以实时视频通信为例,咱们不可能始终保障网络的全时稳固,此时,弱网环境的存在会对进步传输品质起到重要的作用。 援用官网的解释就是:弱网环境长期存在,特地在很多关乎到生存、生产乃至生命的关键时刻,通信网络往往受到极大的物理条件限度,如海事作业、应急救灾、高并发场景等。因而咱们更加须要摸索新实践新办法来无效的剖析、精准的建模、精确的预判,以期实现弱网极限环境下(如极低带宽 <50kbps, 极不稳固网络抖动,极大时延等)的高质量实时视频通信。 马传授先介绍了一下他本人对于视频解决方向钻研了大略十七年左右,目前次要在做两个方面的工作,一方面是对于信息采集的,另一方面是利用相似人脸识别、车流辨认、智能交通等技术进行视频解决,面向人的这样的一个重建。 二、弱网下极限视频通信是什么?引入弱网 弱网和惯例的互联网不一样,惯例的互联网从目前极限的角度来看,曾经是相当的不错。而比如说无论是直播也好还是点播也好,不论从信号处理的角度、视频压缩的角度还是从网络的角度,网络的设施曾经可能满足高清超高清,甚至更多。然而遇到大规模泥石流等状况,基站无奈应用;如果是在海事上,只能用的是通信卫星。然而咱们又须要实时的、及时的、精确的把握线上环境,此时钻研一种极限视频框架就显得非常重要,也就是弱网。 三、极限通信的架构设计和劣势三个方面 一、 从最根本的这样的一些工程设计的角度登程,可能真正全副走向数据挪动。 利用原来的办法进行数据驱动,相似于阿尔法狗-围棋,它外面用了强化学习。把强化学习用到去管制网络带宽,去管制咱们简单的像视频编解码器这样的一些参数。绝对应来说,这些网络的这些参数和编辑码参数都是数字。所以如果咱们通过经验性的去设计他这个,心里可能永远是有一个瓶颈的。 二、那第二个就是经验型的设计,从数据驱动更进一步走到智能化。 马传授在这里取了个题目,叫从阿尔法 go 到阿尔法 zero。说到阿尔法狗在设计的时候,他会为了很多这样的做一个简略的起步,然而到阿尔法 zero 他就会依据本人的这样的模式从最初始的状态,而后缓缓学习。所以也提出了对于端到端的视频通信,利用在线学习,可能学到整个网络互联当中不同的状态。而后提供一个最新的在线学习的模型或者决策,要实现对繁多用户的个性化学习。 三、利用视频核心以及数据通信的模式。联合视频内容或者图像的内容,让通信信息自身在这个用户的这个了解上,或者咱们叫语义层面的这样的一个内容了解上,真正从数据能走向人工智能。相当于在感知中,即便视频丢了一帧或者图像有一些像素的失落,甚至有一些大块的失落,都能够通过一些弥补的办法把它获取回来。 四、智能视频编码在视频信号处理方面,咱们怎么样通过有脑视觉启发的这样的一个神经网络的视频压缩视频编码解决或者这样的一个更低码率的信号处理? 视频压缩它其实是一个十分相似于之前流水线结构的一个过程。从像素而后到编码端,从像素到这个安置流,解码呢从二进制流到像素,它其实是一个信息化的流程。那么这个信息化流程下咱们有一些新实践和新办法应该要挖掘,应该持续去摸索的。 其中提到两大零碎,从人的角度来看的话,咱们从视网膜而后到两头的这样的。叫 optical nerve。而后再到这样的一个外侧膝双层,最初到咱们的大脑,咱们叫高级视觉皮层。那么这也是信息的逐渐的提取和感知了解。 在另一个角度下提出了要用这个生物视觉或者老视觉来启发,利用最根本的信息流,从人眼感 3D 世界中进行网络成像。这样的称之为叫 for the pass way 到两头就是外侧汲取底层,而后再通过不同的细胞到咱们的高级皮层,再到外面这个 aerial,而后这外面每个局部它都有很多这样的一个功能性。目前除了实践上的摸索,咱们称为叫这个刺激性试验,还有很多灵长类动物的这样的一个解剖试验。所以也从侧面证实了这样的信息是怎么样的一个传递过程。 技术上的挑战-复杂度对于之前的一些视频图像的解决,其中有一个很关注的就是它的复杂度。它复杂度也是芯片设计到底是否实现的一个很重要的环节。 解决方案提出了一个新的一种办法,就是咱们是否把这个基于这样一个脑视觉的这样的一个模式可能跟当初的传统的这样的一个视频压缩可能联合起来。这个次要有两个起因,个别是从性能上的。在性能上的话,尽管说咱们当初的图像压缩曾经超过了最新的国际标准。然而在视频聊天的时候,还有肯定的路要走,同时的话就是目前应该有数十亿的设施。已有的这样的一个超大数量存在。所以最无效的办法就是咱们是否在这些已有的这样的设施上可能通过一些简略的革新可能让一些古老的数据失去启发,在视频解决上可能实实在在的用起来。 五、网络自适应传输基于强化学习的视频码率自适应 问题形容及难点 网络的时延抖动会造成可用带宽的实时变动。现有算法次要为 VoD 场最/启发式设计.实时场景中无奈取得将来视频信息且不容忍较大缓冲 解决思路 1.设计高效鲁棒的码率自适应算法预测带宽并动静调整视频编码和发送码率 2.实时码率自适应策略零碎框架,通过历史的视频流化教训主动学习实时码率自适应算法 前期依据学习国际化先进经验,把这个用到了真正的实时零碎外面。而后用这个实时系在互联网上的一个 any game 上进行了一个分布式学习。所以在这外面咱们提出了就是说离线的这样的一个 adaptive time streaming。采集了很多这样的一个网络垂直,也包含像欧洲,像其余实验室给进去的,而后提出了一个网络反馈信号的规范,其中进行了一个演变。 基于强化学习的视频码率自适应一演进 存在问题 1.离线训练过程样本受限 2.模仿环填与理论环境可能不符 3.思考模型模型泛化性能带来的性能损失 解决思路 1.网络情况聚类和分类 2.视频内容服类和分类 3.针对网络情况、视频别离训练离线模型 4.在线模型调优进一步笼罩未思考到的环境情况 六、端到端极限视频通信演示平台做的两个 demo。首先第一个就是跟 any game 做的就是目前整个的这样的一个状态,网络的感知以及这样的一个云游戏。 ...

August 27, 2021 · 1 min · jiezi

关于音视频:Springboot-结合-Netty-实战聊天系统

音视频技术为什么须要微服务微服务,英文名:microservice,百度百科上将其定义为:SOA 架构的一种变体。微服务(或微服务架构)是一种将应用程序结构为一组低耦合的服务。 微服务有着一些显明的特点: 性能繁多服务粒度小服务间独立性强服务间依赖性弱服务独立保护服务独立部署对于每一个微服务来说,其提供的性能应该是繁多的;其粒度很小的;它只会提供某一业务性能波及到的相干接口。如:电商零碎中的订单零碎、领取零碎、产品零碎等,每一个零碎服务都只是做该零碎独立的性能,不会波及到不属于它的性能逻辑。 微服务之间的依赖性应该是尽量弱的,这样带来的益处是:不会因为繁多零碎服务的宕机,而导致其它零碎无奈失常运行,从而影响用户的体验。同样以电商零碎为例:用户将商品退出购物车后,提交订单,这时候去领取,发现无奈领取,此时,能够将订单进入待领取状态,从而避免订单的失落和用户体验的不敌对。如果订单零碎与领取零碎的强依赖性,会导致订单零碎始终在期待领取零碎的回应,这样会导致用户的界面始终处于加载状态,从而导致用户无奈进行任何操作。 当呈现某个微服务的性能须要降级,或某个性能须要修复 bug 时,只须要把以后的服务进行编译、部署即可,不须要一个个打包整个产品业务性能的巨多服务,独立保护、独立部署。 下面形容的微服务,其实突出其显明个性:高内聚、低耦合,问题来了。什么是高内聚,什么是低耦合呢?所谓高内聚:就是说每个服务处于同一个网络或网域下,而且绝对于内部,整个的是一个关闭的、平安的盒子。盒子对外的接口是不变的,盒子外部各模块之间的接口也是不变的,然而各模块外部的内容能够更改。模块只对外裸露最小限度的接口,防止强依赖关系。增删一个模块,应该只会影响有依赖关系的相干模块,无关的不应该受影响。 所谓低耦合:从小的角度来看,就是要每个 Java 类之间的耦合性升高,多用接口,利用 Java 面向对象编程思维的封装、继承、多态,暗藏实现细节。从模块之间来讲,就是要每个模块之间的关系升高,缩小冗余、反复、穿插的复杂度,模块性能划分尽可能繁多。 在音视频利用技术中,咱们晓得其实次要占用的资源是 cpu、memory,而且波及到资源的共享问题,所以须要联合 NFS 来实现跨节点的资源共享。当然,单节点裸露的问题是,如果一旦客户端与服务器放弃长时间的连贯,而且,不同客户端同时发送申请,此时,单节点的压力是很大的。很有可能导致 cpu、memory 吃紧,从而导致节点的 crash,这样,不利于零碎的高可用、服务的健壮性。此时,须要解决的是音视频通信中的资源吃紧的问题,在零碎畛域,通常能够采纳多节点的形式,来实现分布式、高并发申请,当申请过去时,能够通过负载平衡的形式,通过肯定的策略,如:依据最小申请数,或为每一个服务器赋予一个权重值,服务器响应工夫越长,这个服务器的权重就越小,被选中的几率就会升高。这样来管制服务申请压力,从而让客户端与服务器可能放弃长时间、无效的进行通信。 如何应用 Springboot 框架搭建微服务介绍这几年的疾速倒退,微服务曾经变得越来越风行。其中,Spring Cloud 始终在更新,并被大部分公司所应用。代表性的有 Alibaba,2018 年 11 月左右,Spring Cloud 联结创始人 Spencer Gibb 在 Spring 官网的博客页面发表:阿里巴巴开源 Spring Cloud Alibaba,并公布了首个预览版本。随后,Spring Cloud 官网 Twitter 也公布了此音讯。 在 Spring Boot1.x 中,次要包含 Eureka、Zuul、Config、Ribbon、Hystrix 等。而在 Spring Boot2.x 中,网关采纳了本人的 Gateway。当然在 Alibaba 版本中,其组件更是丰盛:应用 Alibaba 的 Nacos 作为注册核心和配置核心。应用自带组件 Sentinel 作为限流、熔断神器。 搭建注册核心咱们明天次要来利用 Springboot 联合阿里巴巴的插件来实现微聊天零碎的微服务设计。首先先来创立一个注册核心 Nacos。 咱们先下载 Nacos,Nacos 地址:https://github.com/alibaba/nacos/releases咱们下载对应零碎的二进制文件后,对应本人的零碎,执行如下命令: ...

August 20, 2021 · 12 min · jiezi

关于音视频:实时语音质量监控

明天次要想介绍下,实时语音的品质到底是什么样的,大略介绍一下这个畛域的一些已有的一些办法,而后会再介绍一下现有的办法,并且介绍一下将来想做的一些事件。 语音品质评估办法首先,大略介绍一下语音品质评估,这个之前就个别从那个办法而言的话,是分为主观的一个评估办法,还有一个主观的评估办法的。那主观性评估办法的话,其实就是齐全靠人的一个情感,那主观其实也是分两种的,一种是我齐全不给你一个原始的参考信号,就是我只给你一段语音,而后你听完之后你来通知我,你认为这在于它的分数是应该是多少,那还有一种办法呢,会给你一个锚点,而后通知你这个是最差的,而后让你去基于这个最差的去做一个评估,这个办法也是在目前论文中用的最多的一种,就是主观的一个评估办法。 主观评估办法对于主观评估办法,依据是不是须要一个原始无损的参考信号,分为有参考的客观条件,有参考的主观评估办法,最早差不多是大略九六年左右,就有一个规范叫 P.861 的,率先就是提出来一种办法,就是给一个无损的,再给一个受损的语音信号,而后来比拟它们的一些类似度,或者是一些听觉的一些伤害,而后来给一个分数。2000 年的时候,进去了一个 p.862,起初大略在 04 年,有一个称为 PESQ-WB 的办法,就把之前 pesq 从 8khz 的测试范畴扩充到 16khz,而后,咱们当初罕用的个别就是这个 PESQ-WB。当初很多论文,其中包含比方:降噪、无损等,都还会用这种办法来做一个评估。差不多到 12 年的时候,ITPO 进去一个新的规范,p.863,这个 POLQA 办法其实是 pesq 的升级版,就是其在噪声的克制上做了一些改良,另外,它的准确性其实还是蛮高的,这里说的准确性,其实就是同一段语调,用 POLQA 测进去的后果,跟人听进去的分数看是否靠近,越靠近,则测试越高的。 有参考主观评估办法P.861 PSQM 最早的规范P.862 PESQ、PESQ-WB,利用最宽泛的有参考评估办法P.863 POLQA,最新的有参考评估办法 无参考主观评估办法P.563,最驰名的窄带无参考评估办法ANIQUE,据作者称准确度超过有参考的 PESQE-Model/P.1201,参数域评估办法xxNet,深度学习域评估办法 其实还是蛮多的,就比如说,最罕用的那个 Itot 的 p.563 办法,其实次要就是只有给他一段语音就不须要给它一个原始无损的语音,而后他它会从它的语音的完整性,而后失去一个噪声的水平,而后看是不是都够晦涩来判断这段语音是不是 OK。如果是它感觉这些 feature 所有的都没有问题的话,它就会给一个高分,如果有一些 feature,十分大的起因可能呈现了,比如说语音之间的断裂,或者是因为噪声过大,它也会给一个绝对低的一个分数,在 p.563 之后,又进去一个 ANIQUE,是美国的一个规范,据其文献称,它的准确度会超过方才讲过的有参考的 pesq 的办法。再有就是参数域的办法,参数域的话,不会对语音信号去做解决,而是去用一些状态信息去做一个预计的事件。比方:这个 E-Model 办法,从采集到回声,再到编码的一整个,如果有哪个模块有一些伤害,它们会把伤害的影响因子从整体中裁剪掉。还有一种比拟新的 p.1201 规范,这个规范包含音频、视频两种评估办法。其中音频局部,次要包含网络参数、编解码、音量参数等。 主观评估办法痛点有参考办法,只能用在上线前无参考办法-传统信号域,利用场景窄、鲁棒性差无参考办法-传统参数域,仅在无限弱网条件下能够放弃精度无参考办法-深度学习,利用场景和语料无限,复杂度略高场景窄准确率差鲁棒性差复杂度高线下测试的线上化在线品质感知能力,其特点是,高准确、广覆盖、低简单、强鲁棒。品质评估足够精确,笼罩绝大多数业务场景,不引入过多算法复杂度,和语音内容弱相干。 上行链路品质评估办法一个规范流程:编码-传输-解码-播放,所以其波及到的因素:编解码器性能、网络品质、弱网反抗算法品质、设施播放能力等。咱们做一组数据测试:在多弱网、多设施、多模式的测试 case 下,该办法的打分与 POLQA 的参考打分 MAE 小于 0.1 分,MSE 小于 0.01 分,误差最大值小于 0.15 分。下图是某设施某模式的多弱网测试后果: 上行链路品质评估办法模块比拟多,而且每个模块独立,所以,首先,每个模块有本人的独立检测能力。比方:回声模块,以后可能会漏掉回声,这一点,自身须要晓得。而后,在所有模块自我检测完之后,在编码之前,还会做对立检测的模块,相当于一个卫士,做整个流程的把关。把所有的场景的共性提取,咱们能够总结为四点: 设施采集稳定性回声打消能力噪声克制能力音量调整能力漏回声的起因其实咱们十分心愿晓得以后是否会漏回声,那漏回声起因总体分为四大类: ...

August 18, 2021 · 1 min · jiezi

关于音视频:音视频弱网下实时视频的极限通信

弱网的场景弱网与惯例的互联网还是不一样的,惯例的互联网对于极限挑战,曾经是不错的。无论是直播、点播,基础设施、网络设备以及压缩解决技术等曾经齐全能够满足高清、超高清、多视点等需要了。但对于弱网来说,比方:应急救灾、近海海事、无人图传、边防监控等,这些场景往往须要实时的通信,但这些场景下,依赖基站通信存在肯定的天然起因可能会导致通信受限,甚至中断。比方:大规模泥石流、地震等自然灾害。 极限通信架构基于弱网理论的场景,以及理论存在的问题,南大实验室提出了一个极限通信的架构,次要体现在三个方面: 数据驱动在线强化学习实现个性化数据通信转向人工智能数据驱动从数十年的钻研教训来看,从最根本的工程设计角度登程,来走向数据驱动,当然,这一点也被证实是可行的:比方:强化学习等来利用到管制网络带宽,视频编解码器等参数,这些参数都是比较复杂的。 在线强化学习实现个性化当然,心愿从数据驱动,能够再更进一步走向自动化、智能化,因为你无奈晓得接触的网络的变动,无奈预计是什么样的散发存在。所以心愿通过最新的在线学习的模型、策略等,实现端到端的视频通信。 数据通信到人工智能大部分的视频通信,目前都是以数据通信的形式存在,例如:交换机等不晓得数据到底是视频,还是图像,还是其它什么的。所以心愿联合视频、图像内容,其自身在用户了解上,或者说语义层面上,真正从数据层走向人工智能。因为在用户感知中,即便视频失落一帧,像素失落,咱们都能够通过弥补的方法给取回来。在网络最差的时候,咱们是否能够在网络不能读取的时候,被动丢包,能够借助一些终端设备来解决。例如:一些比拟风行的手机里包含芯片,这些芯片计算能力很强,能够在网络丢包时,终端给予弥补。咱们后期在做一些测试:当把基于线性的模型推广到数据驱动的话,能把用户感知、视频通信感知的性能晋升百分之十以上。同时,咱们把离线的模型变成在线的模型,能够再次晋升其性能。当然,如果在用户感知的角度被动丢包的话,能够予以晋升。面临的艰难是:如何把这些更好的部署到终端、网络节点、服务器上。 智能视频编码对于大数据量的视频压缩与编码,这是很有必要的。那么,如何把压缩、编码做到最好,这是 30 多年来人们的一个谋求。当然,这些年来,能够看到视频压缩还是有肯定的提高。从 MPEG-1 到 VVC、AVS3,有将近 16 倍的晋升。 在最后,基于现有的实践,想通过人的了解零碎,启发一个新的视频编解码零碎。并且过后有相干的一些实践文章被提出。最初,思考从生物视觉、脑视觉的角度登程,来做这一块的工作。 从工艺角度登程,随着当初工艺谋求的越来越量级化,5 纳米、3 纳米,而且设施功耗、算力等成为最大的思考。那么从 2015 年,谷歌开始研发本人的 GPU。后续的话,苹果、华为等手机端也存在这种减速设施的卡。从工业上是能够这样做的,但其带来的就义是比拟大的。 所以,当初钻研的是,视频图像的内容,无非是人来看,或者是机器用。但都须要了解视频图像的内容,能力更好的决策。所以,看视频内容的时候,有时候是实现一种心理上的感应。比方:看悬疑、悲剧、恐怖等电影,有开心、高兴,也有悲伤。从人的角度,有视网膜,到两头的 Nerve,再到大脑 brain,绝对应的高级视觉底层。这也是信息的部分抽取、剖析、感知、了解。绝对应的,咱们称为机器智能的状况下,就监控而言,前端有相机 Camera,连贯上网络,通过网络会送到相似于城市大脑这样大型的计算中心进行一些决策。这样的一个零碎过程,就相似于咱们人的大脑信息的提取、传输,再到前面的心理决策,很直观。所以,咱们能够从人的这样的一个了解零碎来启发咱们是否通过这样的形式来做。同时,咱们也驳回了一些其余的资料,比方:国内上一些分支也在做这方面的钻研。咱们心愿新的常识来帮忙咱们梳理、启发。在这种状况下,咱们提出采纳生物视觉或脑视觉来启发做这样的一件事。 回到根本的信息流,视频图像从人眼感知到视网膜成像,通过这样的 pathway,到高级视网膜皮层,也会到其余的皮层,V2、V4、MT 等。这才是一个残缺的 visual information flow,科学界也通过解剖剖析这一系列的传输信息的过程。所以,咱们想通过脑视觉、神经科学来做想做的一些事件。在历史发行的很多文章中,在六十年代,美国科学家提出,人眼视觉感知器,感知世界的时候解决大略是 100MB/s,而后通过视网膜上的细胞,进行拆散后,进入外侧系地层,大略压缩 100 倍:1MB/s,而后一系列细胞,再到 V1 高级视觉皮层时,只有 40b/s。因为人眼关注的区域,分辨率会很高,不关注的分辨率会较低。把其放大 10 倍的话,当初最好的视频规范 VVC,在播送的条件状况下,也是 1000 倍左右。同时,人眼对于图像视频是非部分的操作,因为人眼的扫视、转动,对于某些区域、色彩、形态会特地的敏感。这就是注意力机制,德国的一个博士早 20 年开始做,V1 所出现进去的跟这个注意力机制就十分类似,所以咱们加了这个模块:nonlocal attention。前面的一些模块,跟 V1 之后,传输到更深层次的语义,咱们设计成 hyper,次要是帮忙信息的重建与信息的提取。最初做成简略的端到端的对称,通过对称来提取信息表针。很乏味的是,这样的信息表针,不论是图像的像素,或者是多幅图像的静止也好,还是有静止的错落也好,都能很好的表白。所以咱们称为:A Hypothetical Feedforward System with Feedback 这样一个 model,简称 HFF。而后这个 HFF 对于像素都是一个残缺的表白,这个 model 利用到视频压缩、图像压缩,后果还是比拟喜人的。最近的图像压缩曾经超过 VVC 的成果。 对于设计中,也存在肯定的挑战,比方:视频的复杂度。之后提出了一种新的形式,基于脑视觉的形式与传统的视频压缩联合起来,次要是 2 个起因,性能方面,当初图像压缩曾经超过了国内的规范,但视频压缩中还是略低。第二个就是现有的设施上曾经有一些的存在,所以最无效的办法是,是否在已有的设施通过一些简略的 net,这样让新的脑信息的启发解决实实在在的用起来,所以提出了新的计划:Performance/Complexity。这次要的概念是,人的大脑不会像解码器一样,只是局部的解析、最初更多是交融的过程。同时,人的细胞对于不同的图像特色的敏感水平是不一样的。 网络自适应传输首先,通过的 BBR 去做码率管制的话,是比拟无限的。所以,有一个思考:能不能把网络的 trace、network 变动作为一种形式来做强化学习,从而推出基于强化学习的视频网络自适应。学习国内上比拟先进的教训,把这个利用到实时零碎中,产生了离线 ARS 训练算法。当然,比照于以后先进算法 BBR、GCC, 晋升 12%左右的 QoE 性能。然而,这个过程也不是完满的演进,存在肯定的缺点。比方:离线训练的过程中存在样本受限,与理论环境不相符。在收集很多的网络模块,比方:4G 的,那么对于 5G 的网络特色是否不一样。所以须要在线学习,在线学习就网络情况进行分类、视频分类的都须要进行解决。次要波及到网络情况和视频内容的聚类、分类。这样,总算给出一个较优的性能。同时,会对于每个用户的信息进行一个新模型的提炼,当这样的状态与均匀状态的区别太大时,就会应用新模型,同时,会主动部署训练,造成一个模型滚动计划体系。依据最新的演进,那么比照于离线学习的模型,在线学习的性能显著晋升 8.1%的归一化 QoE。从离线的 OffLine ARS,到 OnLine 的 ARS,在内容上晋升的性能还是不一样的,但大部分都有较高的晋升。从离线学习,由部分的环境以及训练的资源受限,到在线学习时,实时的获取用户的信息源以及环境因素,能够很好的为新模型训练提供更多、更好的保障,这样训练进去的模型,能够更好的兼容理论情景下的环境因素等变动,同时,能够在新环境中,作为一些补充、欠缺来生成新的模型,是有利于实时网络模型训练的。 ...

August 16, 2021 · 1 min · jiezi

关于音视频:手把手-Golang-实现静态图像与视频流人脸识别

说起人脸识别,大家首先想到的实现形式应该是 Python 去做相干的解决,因为相干的机器学习框架,库都曾经封装得比拟好了。然而咱们明天探讨的实现形式换成 Golang,利用 Golang 去做动态图像和视频流人脸识别的相应解决。 动态图像人脸识别首先咱们来进行动态的人脸识别,Golang 这边相较于 Python 社区来说绝对少一些,不过仍然有一些优良的库能够供咱们应用。明天咱们用到的就是 go-face 这个库。该库利用 dlib 去实现人脸识别,一个很受欢迎的机器学习工具集,它能够说是人脸识别中应用最多的软件包之一。在产学界有广泛应用,涵盖了机器人学,嵌入式设施,挪动设施等等。在它官网的文档中提到在 Wild 基准测试中辨认标记面部的准确度达到惊人的 99.4%,这也阐明为什么它能失去宽泛的利用。 在咱们开始码代码之前,首先须要装置 dlib。Windows 平台绝对麻烦一些,具体在官网有装置计划,这里我介绍两个平台。 Ubuntu 18.10+, Debian sid最新版本的 Ubuntu 和 Debian 都提供适合的 dlib 包,所以只须要运行。 # Ubuntusudo apt-get install libdlib-dev libblas-dev liblapack-dev libjpeg-turbo8-dev# Debiansudo apt-get install libdlib-dev libblas-dev liblapack-dev libjpeg62-turbo-devmacOS确保装置了 Homebrew。 brew install dlib创立我的项目及筹备工作在 GOPATH 的 src 目录下,创立我的项目文件,命令如下。 sudo makedir go-face-test# 创立 main.gosudo touch main.go而后进入该目录下,生成 mod 文件。 sudo go mod init调用该命令后,在 go-face-test 目录下应该曾经生成了 go.mod 文件。 ...

August 11, 2021 · 6 min · jiezi

关于音视频:Golang-实现-RTP

在 Coding 之前咱们先来简略介绍一下 RTP(Real-time Transport Protocol), 正如它的名字所说,用于互联网的实时传输协定,通过 IP 网络传输音频和视频的网络协议。 由音视频传输工作小组开发,1996 年首次公布,并提出了以下应用构想。 简略的多播音频会议应用 IP 的多播服务进行语音通信。通过某种分配机制,获取多播组地址和端口对。一个端口用于音频数据的,另一个用于管制(RTCP)包,地址和端口信息被分发给预期的参与者。如果须要加密,可通过特定格局进行加密。 音视频会议如果在会议中同时应用音视频媒体,那么它们是作为独自的 RTP 会话传输。音频,视频两个媒体别离应用不同的 UDP 端口对传输独自的 RTP 和 RTCP 数组包,多播地址可能雷同,可能不同。进行这种拆散的动机是如果参与者只想承受一种媒体,能够进行抉择。 Mixer 和 Translator咱们须要思考这样一种状况,在某个会议中,大多数人处于高速网络链路中,而某个中央的一小部分人只能低速率连贯。为了避免所有人应用低带宽,能够在低带宽区域搁置一个 RTP 级的中继器 Mixer。Mixer 将接管的音频报文从新同步为发送方 20 ms 恒定距离,重建音频为繁多流,音频编码为低速带宽的音频,而后转发给低速链路上的带宽数据包流。 分层编码多媒体应用程序应该能调节传输速率以匹配接收者容量或适应网络拥塞。能够将调节速率的工作通过将分层编码和分层传输零碎相结合来实现接收器。在基于 IP 多播的 RTP 上下文中,每个 RTP 会话均承载在本人的多播组上。而后,接收者能够只通过退出组播组适合的子集来调整接管带宽。 RTP 数据包头部字段只有当 Mixer 存在时,才会存在 CSRC 标识符列表。这些字段具备以下含意。前 12 个 8 位组在每一个包中都有。 version (V): 2 bitsRTP 版本。 填充 (P): 1 bit如果设置了填充位,包中蕴含至多一个填充 8 位组,其余填充位不属于 Payload。 扩大 (X): 1 bit如果设置了扩大位则存在。 CSRC 数量(CC): 4 bitsCSRC 数量蕴含在固定头中,CSRC 标识符数量。 ...

August 9, 2021 · 3 min · jiezi

关于音视频:基于-HLS-创建-Golang-视频流服务器

HLS 是 HTTP Live Streaming 的缩写,是苹果开发的一种基于 HTTP 的自适应比特率流媒体传输协定, 并于 2009 年. HLS 流媒体曾经成为利用最宽泛的实时视频协定。它是一种将流分解成基于文件小段的格局, 能够通过 HTTP 下载,HLS 能够通过规范的 HTTP 或代理服务器等,这和基于 UDP 的协定(例如 RTP)不同。既然 HLS 当初如此受欢迎,那么它有那些长处和毛病呢。 长处利用宽泛首先,方才曾经提到过,HLS 是利用最惯犯的实时视频协定。尽管最后苹果是为了本人的生态设计的,例如 IOS,Safari 浏览器等,然而背靠苹果,有弱小的生态和研发能力,当初它简直在所有浏览器上实现了。尽管当初的支流浏览器都反对一个相似的规范,称为 MPEG DASH,然而因为苹果 Safari 浏览器和 IOS 设施不反对它,集体认为 HLS 是一个更好的抉择。自适应比特率HLS 另一个微小的劣势是,它容许客户端依据可用带宽,从各种品质流中选出适合的。HLS 分解成一个个大概 10 秒的文件小段,通过合成,客户端应用程序只须要提前缓冲 10 秒。为用户节约了大量潜在带宽。毛病蹩脚的提早尽管 HLS 设计进去是为了高效的解决多品质的流,但它并不是为了疾速传输视频设计的。实际上,HLS 在流中引入流相当长的提早,个别 20 秒左右,甚至更久。说到这里,你可能想问为什么?HLS 须要三个片段在队列中才容许回放,片段被视频中的关键帧宰割。用 HLS 创立超低提早流的惟一办法就是每 250 毫秒呈现一个关键帧的视频进行编码,HLS 播放列表窗口将是四项长度,减少正在产生的 HTTP 调用频率,并给服务器减少额定的压力。未公布HLS 是一个仅供用户应用的协定。不像 WebRTC 有从浏览器公布的标准,HLS 仅反对播放流,如果你想公布一个设施的实时视频流,你只须要寻找其余的 SDK ,国外的例如 Red5 Pro(场景较为繁多,巨贵), 来创立应用 RTP 的公布应用程序,而后通过 HLS 中继这些流,让人们在浏览器中查看。国内有几个较为成熟的音视频 SDK,例如声网等平台,提供很多场景的音视频解决方案。HLS 简略介绍完了,接下来演示一个小 Demo, 应用 FFmpeg,能够很轻易的将 mp3 文件转换为 HLS 格局,它由多个文件组成,其中一个蕴含元数据(.m3u8),元数据通知客户端从哪里获取每个数据文件,以及数据文件中蕴含什么内容。数据文件拓展名是.ts,通常蕴含 10 秒的音频。 ...

August 6, 2021 · 1 min · jiezi

关于音视频:唐桥科技推出100创新项目共创计划提供免费实时音视频产品支持

云通信专家唐桥科技近日发表推出 “100翻新我的项目共创”降级打算,基于原先的翻新我的项目搀扶打算,带来更大的反对力度。传统企业线上业务场景更加多元化本次翻新我的项目共创打算由原先面向繁多医疗行业全面降级为面向传统IT赛道。在“数字化”和“新基建”的风口上,传统IT行业正在被5G、RTC(实时音视频)、人工智能等新技术赋能,变得更加便捷、智能化。尤其是传统的金融、医疗、教育、交通等行业和公安法院政府机关等单位,在疫情的催化下,业务模式由传统的线下操办,更多的开始向线上扩大,延长出十分多的基于线上的实时翻新互动新场景,重构人们的生存形式。 构想以下几个场景:1. 在线问诊。在家通过视频、图文向医生征询用药与衰弱问题。足不出户,也可享受专业级问诊和护理服务2. 在线诉讼。将法院须要线下办理的事务性工作转移至线上,笼罩庭前会议、庭前调解、证据替换、信访约谈、执行约谈等业务节点。依靠实时音视频互动技术,实现了多方音视频交互、数据合作、即时通讯等性能,让诉讼事务办理从“面对面”变为“屏对屏”。3. 在线执法。通过音视频服务建设近程审判零碎,进行近程取证,有利于固定要害证,同时录制下来的影像材料也可保留留档。4. 在线面签。通过近程连线,实现实现身份核验、面谈、审查审批、合同签订等流程,实用于客户在办理小额经营贷款、近程开户等业务场景。 唐桥基于多年在实时互动音视频畛域的摸索与积淀,赋能企业互动业务转型。为100个翻新我的项目提供收费实时音视频产品反对,蕴含试点我的项目收费实时音视频私有化部署,实时音视频专属技术培训反对,技术计划撑持,以及更多后续优惠政策。帮忙传统畛域企业单位以更低成本,更高效率实现业务的翻新与倒退。 自翻新我的项目共创打算上线以来,唐桥已与多家厂商联结先后落地了智慧公安、智慧法院等公检法场景;还有在线教育、大班小班课等教育场景;同时联合院端,落地了近程会诊,近程超声等医疗场景。 收费我的项目反对、专属技术支持与培训、更多解决方案唐桥推出“翻新我的项目共创打算”次要蕴含收费我的项目产品反对和收费技术支持两块。企业通过唐桥官网申请加入“翻新我的项目共创打算”。 唐桥也心愿在接下来通过“翻新我的项目共创打算”,与更多企业一起共探新场景,共翻新业务。

July 22, 2021 · 1 min · jiezi

关于音视频:技术实践-网易云信视频转码提速之分片转码

在媒体内容流传行业中,视频作为信息流传的载体,其重要性占比越来越高。通常,为了应答不同的播放场景,视频须要批改封装容器格局、编码格局以及分辨率、码率等媒体流属性,这些解决的过程咱们统称其为视频转码。 网易云信集网易 21 年 IM 以及音视频技术,对外提供行业一流的交融通信云服务。其中,云信的点播服务,基于分布式解决集群和大规模散发系统资源,可满足全终端设备的播放需要,为企业用户提供极速稳固的视频上传、存储、转码、播放和下载等云服务性能。云信的分布式工作解决零碎,则承载了其中的媒体解决这一能力,次要性能有音视频的转封装、转码、合并、截图、加密、加减水印等,以及图像伸缩、图像增强、音量归一化等一系列前解决性能。 视频转码作为媒体解决的外围性能,在对大视频文件转码时,通常须要破费较长时间,为了晋升服务质量,咱们将重点晋升视频转码的速率。本次文章将以分片转码为主,介绍网易云信在转码提速方面的致力与成果晋升。 转码性能的影响因子与优化常见的视频转码流程,个别如下图所示: 在转码过程中,瓶颈次要在视频流,因而咱们对速度晋升的探讨次要针对视频流解决,音频流解决暂不在思考范畴内。针对视频流解决的环节,从以下几个方面展开讨论: 源视频:个别源视频越长,那么编解码所需工夫则越长。封装与编解码:对于视频转封装、关键帧片段裁剪等不须要解码编码的解决,其所需计算量很小,个别耗时在1~2s。若须要从新编解码,则依据源视频、编码输入参数的不同,所耗时间也不同。常见的有编码格局以及码率、分辨率、帧率,比方不同编码算法的压缩率与计算复杂度不一样,导致所需耗时也有所不同,举例来说 AV1 编码工夫就大于 H.264 的编码工夫。指标码率、分辨率、帧率等参数越大,通常计算耗时更大。<!----> 计算资源的程度与垂直伸缩:通用处理器的单核计算能力越强,转码耗时必定越小。利用 GPU 这类更适宜图像计算解决的专用处理器,也有利于升高转码耗时。晋升转码执行流的并发计算度,也有利于升高转码耗时。这里的并发路数能够是多线程和多过程,多线程指单过程内以多线程的形式晋升,多过程则为通过对文件切片后,多过程对多个切片文件计算。集群任务调度:多租户的云服务零碎,通常都是基于租户间资源分配优先级和租户内转码工作优先级综合而设计的调度算法,调度效率次要在以下几个方面体现:如何用更少的工夫调度多的工作,如何用更少的集群资源实现高吞吐量,如何做好优先级和防饥饿的衡量设计。针对上述的影响因素,咱们提出以下几个优化方向:晋升硬件能力、优化编码、分片转码以及晋升集群调度效率。 专用硬件加速多媒体解决是典型的计算密集型场景,优化多媒体应用程序的整体计算性能至关重要。CPU 是一种通用计算资源,将视频图像类运算 offload 到专用硬件上是一种常见的计划。目前,业内诸如 Intel、NVIDIA、AMD、ARM、TI 等芯片厂商都有相应的多媒体硬件加速计划,晋升高码率、高分辨率等视频场景的编码效率。 咱们的转码零碎次要基于 FFmpeg 多媒体解决框架,在 Linux 平台上反对的厂商计划有诸如 Intel 的 VA-API (Video Acceleration API)和 Nvidia 的 VDPAU (Video Decode and Presentation API for Unix ),同时两家厂商也反对了绝对更公有的 Intel Quick Sync Video 和 NVENC/NVDEC 减速计划。目前咱们次要采纳了 Intel 核芯显卡的视频减速能力,联合 FFmpeg 社区的 QSV Plugin 和 VAPPI Plugin 两种形式,针对 AVDecoder、AVFilter、AVEncoder 三个模块做了硬件加速。硬件加速相干技术,相干厂商和社区都在继续优化,在咱们的后续系列文章中,咱们也会具体介绍这块的进一步实际。 AMD 大核服务器 这里次要指搭载了 AMD EPYC 系列处理器的服务器,绝对于咱们此火线上的服务器,其单核计算力更强,并行计算能力更优异。单核计算力的晋升让咱们在解码、前解决、编码能有整体性的通用晋升,而搭载超大核则是让咱们的分片转码计划中的单机多过程场景更加锦上添花,大大防止了媒体数据的跨机器IO通信。 ...

July 20, 2021 · 2 min · jiezi

关于音视频:天津大学教授站上-WICC2021-讲坛-将分享边缘计算新研究

寰球互联网通信云领导厂商融云主办的第三届寰球互联网通信云大会(WICC 2021)行将于7月24日在北京柏悦酒店召开。 如果说大会自身是一个为产业界提供“新视界·连将来”的异构解决方案,那么会议的高峰论坛、顶峰对话、技术分论坛,以及游戏等交换互动环节就是多层级架构,来自不同行业讲师的演讲话题则是大会的边缘节点。届时,讲师们将带来哪些“算力”,大会与各环节之间会怎么“云边协同”,都是开发者不容错过的亮点。 依据大会最新曝光,在“网络传输与零碎架构”技术分论坛,来自天津大学智能与计算机部传授、博导,国家海内高层次人才引进打算优秀人才王晓飞,将作为学术界嘉宾,带来《5G 时代的边缘智能与云边协同》最前沿的科研分享。作为钻研边缘智能实践、边缘计算零碎架构和云边协同算法的资深学者,王晓飞传授的加盟将使与会开发者,有机会围绕本畛域话题开展更加深度的交换。 边缘计算实质是算力的基础设施 近年来,边缘计算、云边协同技术备受瞩目。王晓飞传授认为,从倒退程度来看,国内国外处于齐头并进的态势,国内除了与硬件芯片相干的层面有所欠缺,在软件、架构、服务模式等相干畛域,咱们的理念和技术甚至比国外还要先进,当先劣势来自于国内宏大的市场和更快的迭代速度。 边缘计算的实质是无处不在的多层级、异构的算力基础设施,可能把全世界联网的所有算力设施连贯在一起,从大型数据中心,到小型数据中心,再到服务器和智能网关,最初到终端和传感器,全副分割在一起组成一体化的、反对智能社会倒退的最根底算力设施。 因而,边缘计算将来的发展潜力微小,在数据层面、网络层面和计算层面将更加协同,建设在云边协同的架构之上原生的杀手锏利用也会呈现。目前学术界、产业界看到的边缘计算还只是冰山一角。 边缘计算的科研分享与产业落地 王晓飞传授所描述的边缘计算世界无疑会让与会者无比兴奋和期待,他剧透本次分享的内容,次要是从5G时代的网络边缘视角,讲述撑持边缘计算的实践背景,探讨合作边缘缓存、边缘计算、边缘网络和边缘算力的深度交融,梳理边缘智能的外围问题、挑战和关键技术。 作为WICC的新敌人,王晓飞传授将首次站上WICC 2021的“讲坛”。他的研究成果,比方,云边端协同下,资源利用率的调度算法和优化,以及协同时价格博弈和公平性、可靠性钻研,最终利用边缘计算技术大幅度晋升智慧社区、智慧安防、智慧电网等畛域的智能解决能力,这些都将给产业界嘉宾无益的思考和启发。 作为学术界嘉宾,他强调:技术倒退既有科研挑战,也有产业挑战,二者须要交融推动,这就造成了企业与科研院所之间的强依赖关系。学术研究尽管具备前瞻性,有实践的高度和深度,但要与产业充沛交融,还须要吸取产业动静,踊跃与产业界同仁探讨前沿技术在落地中的难点和挑战,这种对接能让科研有据可依,对症下药。 因而,这也是王晓飞传授加入WICC 2021的目标,他坦言道,“融云举办的WICC大会汇聚泛滥行业的精英人才和技术首领,为与会者结识新老朋友提供了互动交换的平台,可能从科研和产业交融的维度,推动产业向纵深畛域倒退。” 将来边缘计算让通信泛在 晋升通信体验 具体到通信云畛域,王晓飞传授的边缘计算研究成果能够晋升通信的数据传输,优化网络和服务体验。例如,音视频直播/通话这一类对低延时、丢包率、带宽抖动等有强需要的业务,都能够通过对云数据中心和边缘数据集群的资源进行联结优化,晋升用户体验与服务质量。 将来,边缘计算将使通信云能力无处不在。因为将来肯定是一个一体化泛在的通信云边协同架构,作为网络服务的基础设施,智能传输可将所有网络节点聚合为一个世界级的大型硬件平台,造成全副算力设施的联动,在平台上运行各种网络服务、计算服务,以及各类智能利用。 聚焦到PaaS层面,王晓飞传授指出,“PaaS次要是平台层,要为下层利用提供撑持。而将来的市场中充斥着大量的异构客户端,具备充沛的差异化业务场景和服务需要。例如,高清视频、高清游戏、主动驾驶和工业物联网等业务场景,底层的算力基础设施也将极其异构和碎片化,如何充沛优化和整合资源,包含为各种边缘节点、各种小型碎片化算力设施提供反对,让每一个用户、渠道和资源都失去最优化的服务质量保障,将远比现有的云服务模式更具备挑战性。” 结语 “学术成绩要转化为产业利用,须要降维。学术研究中,为了达到算力最优,优化参数和束缚都采纳了非常复杂的解法。但在理论落地时,简略粗犷的算法反而更容易在利用上落地。”这是王晓飞传授在前端科研转化为产业利用时的最大感触。 王晓飞传授作为科研界的嘉宾代表,所分享的实践冲破和实际感知,将帮忙产业界在理论利用上关上新视野,WICC 2021融入的学术界新观点,也将为开发者所期待。

July 20, 2021 · 1 min · jiezi

关于音视频:WICC-2021即将召开-荔枝将揭秘高音质体验之关键技术

7 月 24 日,寰球互联网通信云领导厂商融云主办的第三届寰球互联网通信云大会(WICC 2021)将在北京柏悦酒店召开。目前报名参会开发者已过千人,他们的最大获益除了凝听主论坛技术首领的高屋建瓴之外,还有下午技术分论坛,产业中技术领导者分享的先进技术和最佳实际,这些远见卓识将激发出更多产业生机,带动和减速通信云行业的倒退。 在场景化赋能与翻新的技术分论坛中,中国在线音频平台荔枝(LIZI.US)将由高级音频工程师马朋飞带来《荔枝音频体验优化演进》的技术分享,为开发者现场解说荔枝录音/直播架构的演进,以及如何增益音频品质等荔枝核心技术,十分值得期待。 揭秘优化高音质的核心技术 场景化赋能与翻新的技术分论坛,次要为开发者带来基于场景的最佳技术实际分享。作为本次音频场景的主讲人马朋飞,入职荔枝后,次要负责客户端的音频采集、算法解决、编解码、声音渲染、多品种机型适配等工作,并围绕互动娱乐行业提供相应的音频解决方案,确保直播、录播等场景下的高音质音效,积攒了丰盛的实战经验。 技术分享是他参会的目标,他婉言,“在纯音频畛域,真正把技术做精做透的并不多,荔枝的劣势在于声音解决技术,咱们的初衷是用声音把所有的人都分割在一起。所以在音质下面,要花力量,把工作做精,一直将一般音质优化打造成不同利用场景下的高音质,带给用户最佳体验。”分享中,他将对热门的高音质直播场景进行解说。其中,如何解决声音播放中的要害数据是次要技术亮点。 除此之外,荔枝还具备独特的声音智能举荐技术,依据音色、语种,可能定向、更精准的向客户举荐相应的主播节目或音乐。比方依据语种,能够举荐英语、韩语、方言类的节目。联合声音智能举荐技术的利用场景,荔枝将揭秘如何打磨高音质的核心技术,通过精细化的音质配置计划,实现以后场景的最优音质。 差异化的竞争思维让荔枝“真香”,也为开发者所借鉴 在线音频市场因 Clubhouse 的年初大火而增量显著,也让荔枝作为“中国在线音频行业第一股”再次受到极大关注。 荔枝从2013年创建以来,就致力于让人们通过其产品组合用声音将人们分割在一起,通过数年的技术打磨和市场深耕,培育出适宜不同用户群的产品,包含主打UGC音频社区荔枝App;主打通过大V流传海内外精品播客内容和交换互动的荔枝播客。荔枝用多样化、差异化的利用产品提前卡位,占据了先发劣势。 荔枝的胜利再次印证了“时机总是青眼有筹备者”。对于开发者而言,重要的不是跟风市场,而是专研技术,一旦瞄准了研发方向,就要心无旁骛地沉下来,一直摸索和打磨。任何技术畛域,要做到精专,都须要工夫和教训的积攒。这是马朋飞以切身的职业教训给开发者的倡议。 在技术集成实际方面,他给开发者的倡议是:适宜的就是最好的。技术自身没有好坏,要集成一个好的产品,可能面临很多技术计划,各有优缺点,没有一种计划可能满足所有场景,所以,须要在实在的开发验证中,找到最适宜的那一个,成为最好的解决方案。 WICC举办的宗旨就是促成交换,不仅体现在WICC的泛滥技术首领和开发者之间,还体现在产业界各厂商之间。 将来,荔枝将在车载终端的通话体验、VR场景的优质音频技术方面,进行策略布局。荔枝也心愿通过WICC技术盛会,进一步增强与产业界的交换单干,推动整个音频产业向更高质量体验方向倒退。 结语 本届WICC大会,围绕实时音视频作为次要技术分享,其中音频相干的技术内容,除了荔枝马朋飞之外,还有中科院声学研究所研究员李晓东的《通信声学新进展》、融云 iOS 高级开发工程师臧其龙的《基于语聊房场景化 SDK,摸索新一代 PaaS 服务的演进方向》等。届时大会将如何“把耳朵叫醒”,让咱们静待 WICC 2021 的召开。

July 19, 2021 · 1 min · jiezi

关于音视频:网易云信线上万人连麦技术大揭秘

技术系列课回顾 | 网易云信线上万人连麦技术大揭秘本文依据网易云信资深音视频服务端开发工程师陈策在《MCtalk Live#5:网易云信线上万人连麦技术大揭秘》线上直播分享整顿。 导读大家好,我是来自网易云信的陈策。连麦作为一个强互动场景,单房间内的高并发始终是个比较复杂的问题。这次给大家分享网易云信在万人连麦这个场景上的摸索和实际。 比拟典型的万人连麦需要场景有视频会议研讨会、低提早直播、在线教育大班课、类 Club House(多人语聊房)等。对于万人连麦的需要场景市面上广泛的解决方案是“RTC+CDN”的形式,即限度上麦主播人数在小规模(50人左右)进行 RTC 互动,而后转推到 CDN,大规模的观众再通过 CDN 直播拉流的形式实现。这种解决方案在业务上限度了上麦人数,并且观众和主播之间有较大的声画提早,无奈满足云信的业务要求。例如,在游戏语音场景中,会有大量的用户开公麦,须要做到所有人都能够上麦,并且上麦人数不限度。那么,网易云信是如何解决这个问题的呢,本文将和大家分享咱们在这个问题上的摸索。 信令的技术难点信令并发、弱网和高可用问题咱们在这个问题的探讨分为几个方面:信令、音频技术、视频技术以及服务器间的网络传输,先来看看信令的实现。 RTC 是应用长连贯进行双向告诉的。假如某个语聊房主播有一万人,那么只有其中某一个主播上/下麦或者退出/来到房间,都会触发对其它 9999 人的信令告诉。这种随机的用户行为会让服务器刹时压力十分大。 传统的中心化单点服务器显然是支撑不了万人房间这么大并发的,必须应用分布式架构来扩散压力。如果一个万人房间散布在多台服务器上,那么服务器之间还要实时同步 Nx(N-1) 的用户状态和公布订阅关系,同时为了实现高可用,还须要反对某台服务器解体重启后的数据同步。 另一方面,媒体服务器个别会做成分布式网状架构来升高点对点的提早。但如果信令服务器也放弃每一个节点都平等的网状架构,那么每一个节点都要保护全量的级联关系。这其中盘根错节的音讯同步性问题将会极难保护。 网易云信分布式树状架构为了实现高并发和高可用,联合信令都是在房间外部传递,房间之间不会有信令交互这一业务特点,咱们将信令服务器设计成分布式树状架构,每个房间是一颗独立的树,如下图: 根节点:房间治理服务器,治理和存储所有的用户状态和订阅关系。子节点:作为边缘服务器,负责用户就近接入。 这种树状架构能够无效扩散各节点的播送压力。根节点会尽量依据就近用户的准则进行调配,防止其与子节点之间链路过长,同时子节点尽量只充当音讯 proxy,不参加业务,把业务集中到根节点上,从而防止信令的同步乱序等问题。 根节点应用缓存加数据库来保障业务数据存储的性能和可靠性。子节点因为不波及用户业务状态,在解体重启后,只须要客户端信令的长连贯重连,不必进行相似重新加入房间的操作,做到对用户无感知。在遇到子节点宕机的状况下,则会依附客户端的超时机制,从新申请调度。通过这一系列伎俩,实现服务的高可用。 信令弱网问题在RTC架构中,因为信令十分多且交互简单,个别采纳信令和媒体通道拆散的策略。但这会引入一个问题,就是两者的抗弱网能力不统一。媒体个别应用Udp传输,很容易做到在30%丢包下仍然能流畅观看。但信令个别应用Tcp传输,30%丢包下信令就根本不可用了。 为了解决这个问题,咱们应用Quic作为信令减速通道,来保障信令媒体的弱网反抗能力一致性。同时在Quic连不通时(可能存在用户网络对某些Udp端口不敌对),也能退却到Websocket,以此来保障信令在弱网下的高可用。 音频的技术难点混音和选路的缺点在多人连麦场景中,最简单的就是多个用户同时谈话场景下的音频并发问题。 假如万人房间中每个主播都上麦,因为语音的个性,每个主播实践上都要订阅其它所有人(视频能够按需订阅,但音频实践上应该全订阅)。如果每个客户端都订阅 N-1(9999) 路流,不仅仅是流量的节约,客户端也反对不了如此多的上行,而且在事实场景中,只有超过 3 集体同时谈话,其他人基本上就听不分明内容了。 解决这个问题的办法个别有音频选路和服务端混音两种。但在万人房间的场景下这两种解决方案都有所缺点: 音频选路是在 N 路音频中抉择音量最大的几路进行下发(个别 2~3 路)。这个计划的确可能解决上述问题,但它有一个前置条件:与客户端直连的边缘服务器上必须会集全量的音频流,这样能力选路。所以,即便是 48 核的服务器,也难以反对万路并发。服务端混音是解码 N 路混成1路,或者选路之后再解码3路混成1路。前者的问题次要是MCU 服务器很难顶住这么大的转码压力,而且耗时过长。后者还是会有上述音频选路的缺点。其实MCU最大的毛病是单点问题,解体后会影响全量的用户,很容易成为零碎瓶颈。网易云信的分布式选路为了解决音频的上述问题,咱们采纳了在服务器级联之前预选路的计划。假如一个万人房间均匀散布在 20 台边缘服务器上,每台服务器有 500 路上行流,如果不应用级联预选路,那么每台服务器相互级联后,都须要拉全量的 10000 路流能力供上行选路应用。 当咱们应用级联预选路计划后(默认 3路),每台服务器只须要拉  3x(20-1) 路流就能够,之后再从本机的 500 路流加上级联的 3x(20-1) 路流中进行二次选路,选出最终音量最大的3路流下发给客户端。通过这种形式,实现音频的全订阅。假如在 M 台服务器上传输 N 路音频流,服务器传输数据量的数量级就从 N^2 降落到 M^2。 ...

July 16, 2021 · 1 min · jiezi

关于音视频:WICC-2021召开在即-清华大学教授将分享AI网络音视频服务研究

走进7月,由寰球互联网通信云当先厂商融云主办的第三届寰球互联网通信云大会(WICC 2021)也进入了倒计时。WICC一贯以预感通信云畛域的前沿科技,引领行业倒退为己任。本届大会以“新视界·连将来”为主题,上午的高峰论坛中首次邀请到清华大学传授孙立峰坐而论道,围绕“AI+网络音视频服务”的钻研热点,介绍了AI与音视频相结合的技术发展趋势。 这也是 WICC 2021 响应国家政策疏导,推动产学研深度交融,从学术研究方向带给开发者的新亮点,心愿理解音视频新技术与利用的小伙伴们能够重点关注。 促成产学研的深度交换与单干 作为大会促成产学研交换层面的学术界代表,孙立峰是来自清华大学计算机科学与技术系的长聘传授,在国内期刊和会议上发表的论文达120余篇,受权国家发明专利20项。钻研趣味集中在流媒体技术、多媒体边缘计算、视频智能剖析与解决、媒体大数据与社交媒体计算。钻研特点在于:在根底钻研的同时,重视与产业联合,解决产业利用面临的理论问题。 此前,孙立峰传授所领导的课题组,开发了“3D视频编码与网络直播零碎”,利用于央视2012年CCTV网络春节联欢晚会和欧洲足球锦标赛的3D网络直播,这是国内首次通过互联网发展的大规模3D视频直播服务,为广大观众提供了全新的收视体验,失去了业界的高度关注。 课题组还与华为公司单干,研发的基于深度强化学习的视频码率自适应算法,集成到华为畅连音视频通话产品中,已胜利部署在华为Mate30、P40等多款手机平台,无效晋升了简单网络环境下手机终端视频实时通信的画质和晦涩度。 因而,孙立峰传授认为:“通信云和网络音视频服务是疾速倒退的畛域,特地须要学术界和产业界深度交换与单干,解决行业倒退的瓶颈难题,解决产业一线面临的理论问题。融云举办WICC大会,可能为业界提供一个交换的平台,增强产学研的单干,通过独特研究,清晰产业倒退的趋势,这是我十分违心来参加的起因。” 从AI赋能到智慧内生,是互联网音视频服务的发展趋势 音视频服务已成为互联网信息服务基础设施,特地是后疫情时代,在线教育、视频会议、近程医疗、直播购物等利用场景,更成为人们生存、工作、娱乐的“新常态”和“新业态”。高质量、低提早互联网音视频服务用户体验面临的挑战包含云边端大规模零碎的复杂性、网络状态和用户行为的动态性等。 因而,孙立峰传授在上午的高峰论坛中,将为开发者带来《互联网音视频服务:从 AI 赋能到智慧内生》的主题演讲。他认为,AI,特地是以深度学习为代表的机器学习近年来获得了长足的提高,曾经开始为各个领域赋能。网络音视频服务、云计算面临超大规模零碎复杂性和不确定性的挑战,机器学习将为解决这些挑战提供新的思路和技术路径,通过新的机器学习框架实现零碎自我演进达到智慧内生,是互联网音视频服务的发展趋势。 孙立峰传授的演讲将从学术前沿和产业实际的角度登程,论述互联网音视频服务的个性与挑战、AI+ 互联网音视频服务的技术倒退路线图,帮忙开发者理解以后互联网音视频服务的利用场景和技术挑战,理解 AI+ 互联网音视频服务的技术框架、学术界/产业界的前沿摸索与实际,以及互联网音视频智能服务畛域的发展趋势。 5G与AI等尖端技术的交融,将为通信行业带来新的扭转 在谈到随着5G的进一步落地,以及5G与AI、AR/VR等技术交融,将为通信云行业带来的扭转,以及新技术下产生的新场景所具备的特点时,孙立峰传授认为:5G的进一步落地将带动工业互联网的倒退,通信云从计算的角度将更加关注边缘计算,云边端/云网端的新型计算模式值得钻研;从传输的角度将从传统面向用户(人)的服务质量与用户体验,拓展到思考机器与机器,设施与设施之间的数据传输需要。 将来,孙立峰传授仍将聚焦在AI畛域,面向云边端/云网端的利用场景,新的去中心化的机器学习及其在通信云中的利用,钻研如何实现智慧内生与零碎自我演进。这些新钻研,将来在3D视频的互联网应用领域,一方面能够带来新的视觉体验,另一方面将促成虚拟环境和事实世界的进一步交融,催生新的经济模式,比方近来衰亡的元宇宙的概念,曾经引起了产业界的关注。孙立峰传授心愿学术界的研究成果可能通过多种单干形式实现产业落地,真正服务于产业的理论利用中。 结语 WICC 2021还在紧锣密鼓的筹备当中,从已有的剧透能够看出,融入学术界元素,促成产学研的深度联合,是本届大会非常值得期待的新内容和新亮点。将尖端科技的研究成果赋能于更多通信云场景利用,将为将来通信云技术的倒退和利用削减有限可能。

July 9, 2021 · 1 min · jiezi

关于音视频:融云视角-社交泛娱乐发展趋势对通讯服务行业的影响

本文通过剖析社交泛娱乐利用的市场现状,总结产品共性,再联合与用户相干的各种环境趋势,对行业将来的倒退做出初步判断,并据此评估对通信行业产生的影响,为业内读者在实际操作上提供方向和思路。 一、市场现状 通过观察 App Annie 2021 年第二季度的社交娱乐滞销榜,统计音视频通信相干 App 的上榜状况,咱们发现在榜单的前30 名中,直播类 App 与匹配交友 App 共计占比 60%,相亲、UGC+、休闲桌游共计占比 40%。这阐明用户更偏差把集体工夫破费在直播类和匹配交友类 App 中, 同时也造成了对游戏陪玩、在线 K 歌、在线相亲等多元化社交需要。 那么在这五类利用中,咱们是否能找到其业务共性,从业务角度初步摸索行业趋势呢?通过剖析上述 30 个利用的商业化伎俩,列出表格如下: 语音房和视频直播场景在各类利用中的占比分布图如下: 不难发现,在这五大类利用中,为用户提供语聊房和视频直播场景,是商业化变现的次要伎俩。现阶段社交泛娱乐利用市场,曾经造成了以视频直播和语聊房为外围,内容涵盖秀场直播、游戏直播、语音聊天室、语音直播、语音电台、游戏陪练、游戏匹配等,为用户提供了情感交换、娱乐技能等多方面的服务体验。至此咱们能够得出,视频化、语音化,已成为支流社交泛娱乐利用的发展趋势。 二、用户需要趋势摸索 To B 企业的外围业务,是为客户提供满足其指标用户需要的底层能力。可见客户向咱们提出需要的驱动起源,仍是宽广用户群体。社交泛娱乐的行业趋势,归根到底是宽广用户的需要趋势,而用户需要又与社会环境、经济环境、科技环境、政策环境密不可分。上面通过对 C 端用户环境的剖析,尝试摸索用户需要的趋势。 社会环境 新冠疫情影响下,人们将娱乐的重心转移到线上,打游戏、看直播、游戏陪练、语音聊天等成为泛滥用户在线娱乐及在线社交的抉择。在此影响下,娱乐社交行业用户规模在 2020 年有较为显著的增长,整体用户规模达到 3.7 亿人,同比增长 17.3%。在将来,随着用户娱乐需要及社交需要的晋升,游戏用户将继续向游戏直播用户及游戏陪练用户转化,语音技能服务也将吸引更多年轻人参加,带动娱乐技能社交用户的进一步扩散。 随着娱乐社交行业市场影响力的继续晋升,越来越多的年轻人退出其中。2020 年上半年,受疫情居家影响,线下待业受到较大冲击,而娱乐技能社交行业为广大青年人才提供了大量灵便待业的机会,依据艾瑞征询推算,2020 年娱乐技能社交行业分享者新增规模达到 513 万人。 经济环境 2020 年,中国的互联网经济规模曾经超过 6 万亿元,同时,与次要发达国家相比,中国的网民渗透率还有 15%-20% 左右的晋升空间,能够预感中国互联网经济仍放弃可观的增速,预计在 2022 年规模将超过 8 万亿元。而线上娱乐作为互联网经济的重要组成部分,随着人们在线娱乐时长和娱乐需要的继续晋升,在将来仍有微小的增长后劲。 科技环境 国内通信技术的大范畴遍及与笼罩,推动了挪动互联网行业的疾速倒退,将在线娱乐内容带给更多人。而泛滥新兴技术的翻新和冲破,将带动挪动互联网进一步降级。如 5G 技术的商业化使用,与 4G 相比,5G 具备传输速度更快、时延更低、分辨率更低等特色,将其使用到超高清直播,或与 VR、AR、AI、云游戏等技术联合,将发明出各种高质量、强交互线上娱乐内容,实现互联网娱乐内容和互联网社交模式的迭代降级。 政策环境 政府在对线上娱乐履行严格监管、标准行业衰弱倒退的同时,配合出台一系列政策来促成线上娱乐产业的倒退与转型降级。从近两年的政策能够看出,娱乐技能社交这类新兴线上娱乐行业失去了较大的反对力度,对其将来的倒退将会大有助力。 通过以上剖析,咱们可总结出,在激励与监管并施的政策之下,会使行业将来更加规范化、阳光化。同时,年轻人带着他们善于的娱乐技能踊跃退出行业,会促成平台服务更加专业化。科技的倒退,会进一步推动产业模式降级。Z 世代年轻人出现进去的多元化社交需要,推动着社交场景的交融与翻新,他们也势必成为行业生产的主力。 三、对通信服务行业的影响 ...

July 8, 2021 · 1 min · jiezi

关于音视频:音视频系列一基础知识

title: 音视频系列一:基础知识categories: [C++]tags:[音视频编程]date: 2021/07/01 <div align = 'right'>作者:hackett</div> <div align = 'right'>微信公众号:加班猿</div> 音视频系列一:基础知识开篇:5G时代曾经开启,音视频产业会有质的飞跃,随着知识产权和版权保护数字技术倒退,数字音视频会实现爆发式增长,将来会造成一个全域的音视频服务生态,因为各方面须要音视频相干常识,于是决定开一个音视频系列的坑,接下来会一期一期地缓缓填。 一、音视频录制概念 二、音视频播放原理 三、图像示意概念1、RGB格局 2、YUV格局Y'UV的创造是因为彩色电视与黑白电视的过渡时期。黑白视频只有Y(Luma,Luminance)视频,也就是灰阶值。到了彩色电视规格的制订,是以YUV/YIQ的格局来解决彩色电视图像,把UV视作示意彩度的C(Chrominance或Chroma),如果疏忽C信号,那么剩下的Y(Luma)信号就跟之前的黑白电视频号雷同,这样一来便解决黑白电视机与黑白电视机的兼容问题。Y'UV最大的长处在于只需占用极少的带宽,因为人眼对亮度敏感,对色度不敏感,因而缩小局部UV的数据量,但人眼感知不到。 YUV也称为YCbCr,对于每个重量如下: Y:Luminance, 亮度,也就是灰度值。除了示意亮度信号外,还含有较多的绿色通道量。U:Cb,蓝色通道与亮度的差值。V:Cr,红色通道与亮度的差值。 四、音频概念数字音频包含:采样频率、采样量化、编码 五、视频概念 六、封装格局概念 七、音视频同步概念 如果你感觉文章还不错,能够给个"三连" 我是加班猿,咱们下期见

July 1, 2021 · 1 min · jiezi

关于音视频:华为云基于云原生媒体网络又出重磅新品

摘要:华为云TechWave云原生媒体服务专题日上,华为云媒体服务产品部云视频总监陆振宇发表演讲《云原生媒体网络,降级传统,赋能将来》,分享了为什么要重构媒体网络,基于华为云的云原生技术构筑起来的媒体网络可能解决以后什么问题,以及为什么云原生是将来媒体网络的必选项。本文分享自华为云社区《华为云基于云原生媒体网络,又出重磅新品》,原文作者:音视频大管家 。 6月25日,华为云TechWave云原生媒体服务专题日在线上胜利举办。华为云音视频服务正式降级为媒体服务。降级后的媒体服务,反对媒体生产、媒体散发和媒体利用三大场景。在专题日上,华为云媒体服务产品部云视频总监陆振宇发表演讲《云原生媒体网络,降级传统,赋能将来》,分享了为什么要重构媒体网络,基于华为云的云原生技术构筑起来的媒体网络可能解决以后什么问题,以及为什么云原生是将来媒体网络的必选项。以下内容依据发言内容整顿,有删减。 挑战与时机并存:传统网络已不适应流量的激增和新的业务状态在过来的几年中,咱们看到随着挪动互联网还有5G的提高,寰球的流量尤其是视频的流量5年内减少了12倍。咱们看到很多1080p、4k、8k、VR的视频,使得网络的流量和带宽迅速撑爆。 传统的CDN和直播,可能很好地解决点播视频以及传统直播视频的散发,但应用场景受限,因为有3~5秒的时延,并不能撑持双向互动,实时交互的视频散发场景。比方超低时延的直播、实时音视频、以及一些视频监控的场景,这些业务的状态对于媒体散发的能力提出了更高的要求。 在直播带货的场景当中,常常是主播开始介绍产品,用户端显示链接曾经上了,可是5秒当前,用户才听到主播说倒计时开始,5、4、3、2、1上链接,如果这个时候用户再去点击链接,会发现这个商品可能曾经抢完了,就是因为直播和文字之间有5秒的时延。在这样的场景中就须要1秒以内的超低时延直播,这是当初的媒体散发的能力所不具备的,咱们叫“来不及”。 还有一个场景是“用不起”。大家都心愿把视频摄像头里的内容低成本、疾速地接入到云上,因为云上有大量的AI能力,有很多业务翻新,能够使视频发明出更大的价值。以以后的模式计算:以一个一般的小型园区为例,100路摄像头每路的带宽1兆,是100兆,这样一个云宽带的接入老本,每年就会在12万元以上,这是大家远不能接受的。受限于用不起的老本,很多园区只能把这些视频内容存储在线下,带来的问题是这些视频内容资产不能很好变现,不能发明更多的价值。 辞别传统网络:具备交融媒体节点、分层设计、AI调度特色的云原生媒体网络应需而生为了解决“来不及”、“用不起”这样的问题,华为云提出了云原生的媒体网络,咱们认为云原生的媒体网络应该有三个特色:交融的媒体节点;三、四、七层分层网络传输优化;AI的智能调度。 交融媒体节点 过来咱们有CDN的业务,就有CDN的节点,有直播的业务,就有直播的节点。RTC、视频监控每一个业务都有本人的节点,这些节点不能共享,不能弹性,业务的部署会受到很多的限度。 华为云做的第一件事件,就是把寰球的2500个节点,对立用云原生的形式进行革新,升级成交融的媒体边缘节点,它的特色在底层是对立的计算存储资源,在下面用原生的IEF进行对立的革新和纳管,这样CDN、直播、RTC、XR、转码等都是运行在云原生能力根底上进行动静部署的业务。 每个业务能够依据本人的须要,在白天、早晨别离进行调度,应用上行、上行的带宽以及计算存储的资源,这样边缘资产实现了盘活,能够大幅升高业务传输时延和更重要的业务老本。 分层设计 咱们用分层的思维进行网络传输的优化:相似于TCP/IP要思考音视频内容,在网络上传输时,它所遇到的丢包、时延以及不同网络接入条件下不同参数的问题,咱们用分层的思维来解决,分为3层,4层和7层优化。在3层也就是IP层,咱们提出了天路,它能够实时感知网络,使得转发和路由失去优化,来改善报文转发的时延,进步报文的达到率。通过实测,咱们能够把 IP网上、IP报文的转发时延升高30%,进步0.5个报文达到率的百分点。 同样在4层也就是传输层,提出了华为自研的hQUIC协定,使下层利用开发不必去感知上层具体是跑在什么样的网络介质上,是WiFi、5G还是其余什么样的网络。它能够使得音视频业务,实时音讯传输业务、将来的XR云游戏业务的内容在不同的网络状况下失去别离的减速,进步网络传输的效率。 在7层,在各个业务场景中去解决音视频业务传输的问题。比方是否要先进行一些编解码,再传输,来提高效率?是否要进行一些编解码参数的自适应,在传输两头是否有更好的体验……这些都是在7层实现的。咱们通过分层,在3、4、7层进行优化,使得媒体网络能够对不同的音视频内容在不同的网络上都提供十分好的一致性的体验。 AI调度 咱们提出了Mesh化的调度引擎,这是咱们和国内Top1的学校单干诞生进去的成绩。它有两个要害特色,第一个特色是多业务的对立调度,多业务包含了点播、直播、RTC、监控等,咱们能够将体验和老本做互补调优,实现多业务端到端对立调度能力,不同的业务都由这个调度引擎来对立调度。 第二个特色是不同服务 SLA,采取不同的调度策略,来撑持不同客户的商业策略。比方对于直播,咱们比拟关注回源率?、带宽的趋势、卡顿率等老本和体验指标,咱们就把这些指标作为一个输出,给调度引擎,在2500个节点两头,总是抉择最优的节点进行动静的部署和弹性的伸缩以及最优的服务。 面向RTC这样实时性更高,互动性更强,体验指标更刻薄的场景,咱们就会把用户的首帧时长、卡顿次数、入房成功率、端到端时延,等参数组输出到调度引擎当中,使得RTC总是提供更好的用户体验、更低的时延,助力客户的业务。为了实现这样的调度能力,咱们在调度零碎的实现上进行了Channel级的调度。 咱们对视频的接入阶段、回源阶段及整个网络都是依照一张Mesh的网络进行整体的调度和优化,并且引入了人工智能的形式,来对调度的算法进行自学习,自训练,一直反抗,生成更好的调度策略与算法。通过对立降级的媒体边缘网络,咱们的AI调度,以及3、4、7层的网络传输分层的优化,使得咱们的云原生媒体网络能够解决“来不及”、“用不起”的问题。 给大家举两个例子,第一个例子是在这样的媒体网络之上,咱们能够对直播服务升级成超低时延直播,当初的直播有3~5秒时延,咱们会把直播用RTC的形式降级为超低时延直播,使得时延升高到800毫秒以内,然而其余的业务指标体验,首屏卡顿还和传统的直播持平,这样的服务会帮忙直播,包含电商,教育行业进行一个大的体验降级。 同时如果客户违心承受它的架构站从直播转移到RTC,咱们还能够在这样一张云原生的媒体网络上间接提供RTC的服务,把客户的传输从TCP变成UDP,带来进一步实现体验的降级和时延的升高。 第二个例子是云原生的视频监控服务(VIS服务),它也是基于云原生的媒体网络,把网络中的上行流量充沛复用,使得摄像头的接入价格更亲民。从我方才举的例子来说,从300元/月,降到每月两位数,能够使每路摄像头的运维老本大幅升高,并且促使用户把摄像头生成的内容放在云上,享受更低成本的存储,以及云上更多的翻新和AI的能力,咱们能够使用户每月的老本做到过来的10%以内。 重磅新品:凋谢、共享、高效、平安的视频接入服务,基于边缘协同的架构,反对多业务场景 明天我很荣幸来公布华为的VIS服务产品,Video Ingestion Service,视频接入服务。视频接入服务是华为云上基于边缘协同的架构,一个凋谢、共享、高效、平安的视频接入服务。它撑持多个业务场景,反对视频摄像头,相似于国标28181 视频协定、RTMP视频、FLV视频的接入,咱们后续还会一直减少对SRT以及更多智能摄像头、视频接入协定的反对。 同时咱们还会一直的去拓展服务的边界,降级服务的价值。视频的内容回到了云上,只有和更多的行业生态碰撞,才有可能产生更多的翻新,带来更多的价值。 华为云上不仅有自研的算法,还有凋谢的算法商城,有很多的第三方算法,这些算法是继续演进,有限叠加的。咱们深信只有把更多视频低成本的接入到咱们的云上,才会发明更多的价值。那么接下来咱们能够看一个小视频,看看华为云视频接入服务怎么样可能很轻松的让视频摄像头的内容上云。 很快乐明天向大家分享了华为云云原生的媒体网络,咱们介绍了咱们遇到的挑战,介绍了华为怎么样通过交融媒体节点,3、4、7层的分层优化,以及AI调度,形成一张新的云原生媒体网络来解决这些问题,咱们为之推出的超低时延直播、VIS视频接入这样的产品。谢谢大家。 点击关注,第一工夫理解华为云陈腐技术~

July 1, 2021 · 1 min · jiezi

关于音视频:融云技术如何使用-Telecom-构建-VOIP-通话应用提高APP用户体验

Android 收紧权限后,如何利用 Telecom 技术构建 VOIP 通话利用,晋升 App 用户的应用体验置信是开发者比较关心的技术话题之一。本文从 Telecom 框架概览、Telecom 启动过程剖析、构建 VOIP 通话利用、解决常见的通话场景几个方面,率领大家领略融云如何应用 Telecom 构建 VOIP 通话利用。 一 、背景及现状 Android 低版本收到 IM 语音通话,通过在后盾启动 Activity,能够间接跳转至通话界面;但 Android 10 及更高版本上收到 IM 语音通话时,只能通过弹出告诉栏的形式揭示用户,这种形式不直观,也可能漏接通话,用户体验不佳。 因为从 Android 10 开始,零碎限度了从后盾(组件)启动 Activity 的行为。这样有助于最大限度地缩小对用户造成的中断,让用户更好地管制其屏幕上显示的内容,减少用户体验和安全性。后盾利用启动,必须通过“显示告诉”的形式来进行,告诉用户借助 notification 来启动新的 Activity。 在本文中重点介绍 Android Telecom 及应用 Telecom 构建 VOIP 通话利用,在 Android 高版本实现 IM 语音通话的复电界面跳转。 二、Telecom 框架概览 Android Telecom 框架治理 Android 设施上的音频和视频呼叫。其中包含基于 SIM 的呼叫(例如,应用Telephony 框架)和由 ConnectionService API 实施者提供的 VOIP 呼叫。 如图一所示,Telecom 负责通话状态音讯上报和通话管制音讯下发。 图一:Telecom 音讯解决模型 ...

July 1, 2021 · 3 min · jiezi

关于音视频:8问8答一篇文章读懂空间音效

近日,第一届网易团体创新奖评比落下帷幕,网易智企“迫近人耳极限-音频通话”我的项目从泛滥参赛作品中怀才不遇荣获“0-1创新奖”三等奖。 此次获奖的我的项目诞生于网易智企旗下网易云信的音频实验室。从2020年初至今,音频实验室团队在稳固的音频通信品质根底之上,一直的进行摸索和翻新,“从0到1”胜利研发和落地了多个翻新算法,包含了实时AI音频降噪、Noise Injection、挪动端双讲检测、实时语音 3D 音效、实时智能音乐场景检测等。 其中,实时语音 3D 音效在 RTC 行业内属于独创,不仅实现了实时的 3D 空间音效,还退出了间隔衰减以及房间建模个性。 很多敌人晓得空间音效是因为“吃鸡”等第一人称射击类游戏场景,然而空间音效是如何实现的?目前有哪些支流计划?能够利用于什么场景?对产品甚至行业有什么价值? 明天,咱们通过8问8答,一篇文章让你全面理解空间音效。 本篇文章蕴含以下3个局部: #01通用篇:小白也能看懂 Q1 什么是空间音效?Q2 如何听到空间音效?Q3 空间音效的基本原理是什么?Q4 空间音效的成果受哪些因素影响?#02技术篇:大牛理解一下 Q5 空间音效的技术难点次要在哪里?Q6 空间音效目前有哪些支流计划?#03场景篇:问价值?看这里就对了! Q7 空间音效具备什么样的特点和劣势?Q8 空间音效能够利用于哪些场景?通用篇:小白也能看懂Q1 什么是空间音效?维基百科是这样介绍的:3D 音效也称空间音效(Spatial Sound),是一套能够操控立体声扬声器、环绕声扬声器、扬声器阵列或者耳机所产生声音的音效。它能够将音源虚构成从三维空间特定地位收回,包含听者水平面的前后左右,以及垂直方向的上方或下方。 实质上,空间音效就是基于人耳的一些非凡心理声学效应,通过一些声学相干算法计算模仿,仿造出仿佛存在但理论是虚构的声音。 例如游戏中,敌人偷偷呈现在你左后方时的脚步声,伙伴在你左边换弹夹的声音,右边窗户被打碎的声音,和右前方手榴弹的爆炸声。 Q2 如何听到空间音效?事实上,咱们能够通过很多种形式实现听到空间音效的目标,比方应用扬声器或耳机。这里依据应用目标、利用场景的不同,总结了 4 种形式: 应用多个扬声器创立空间音效的一种办法是在一个空间中搁置多个扬声器,当通过环绕声零碎凝听电影配乐或音乐时,能够将单个元素平移到与凝听者头部雷同的立体上的任何地位。对话、音乐和音效仿佛来自扬声器或介于两者之间的任何中央。这是电影院以及家庭影院罕用的解决方案。 (图源见参考文献) 2. 应用串扰打消技术的条形音箱或立体声扬声器 如果你想领有一个家庭影院,这可能是性价比更高、更不便的抉择。应用串扰打消技术的智能条形音箱目前曾经能够提供残缺的 3D 体验。串扰打消技术在用扬声器渲染双耳信号方面起着重要作用,它次要是通过预失真滤波器,让扬声器播放的声音在特定声学传输门路下面产生相位对消。简略说来,就是从右扬声器传到左耳、从左扬声器传到右耳的声音被对消。串扰打消滤波器应依据头部地位实时更新,因而须要头部跟踪以达到最佳运行成果。 3. 应用动态双耳混音的耳机 在应用耳机的状况下,能够基于上混或者 diffuser 滤波器等技术,产生多声道音源,而后对各个声道数据进行HRTF卷积滤波,从而减少声音的方位感。适当联合混响效果器的应用,能够产生特定 3D 声场成果。该办法的一个次要劣势在于能够打消“头中效应”,实用于游戏以及电影场景,能够带来肯定的沉迷感。华为手机常见的 histen 音效中的 3D 沉迷以及 3D 巨大模式,次要是基于这类技术实现。 4. 联合应用头部跟踪和头部锁定音频 双耳声音的耳机通常听起来并不实在,局部起因是当你转动头部时它不会扭转,因而头部追踪是十分重要的。例如,应用光学相机办法或陀螺仪传感器跟踪你头部的地位和方向。双耳渲染能够整合你的动作,这意味着能够依据你的头部旋转和地位来更新渲染。 (图源见参考文献) 苹果就是通过 AirPods Pro 内置的减速传感器和陀螺仪,对佩戴者的头部进行实时追踪,当头部挪动时,能够对数据进行从新计算,以便佩戴者听到的环境音效与最后的成果统一。除了能够对佩戴者的头部实时追踪外,AirPods Pro 的传感器还可能追踪头部和设施之间的静止数据,并且反对数据比照,以确保用户在乘坐地铁或公交遭逢到紧急刹车的情况时,盘绕音效不会中断。 ...

June 25, 2021 · 2 min · jiezi

关于音视频:七牛云-霍锴SDK-是一款技术服务的门面如何方便用户高效接入是前提|ECUG-Meetup-讲师专访

6月26日下午,「 ECUG Meetup 第 1 期·杭州站」邀请到了来自七牛云的音视频客户端专家霍锴进行现场分享,「醉心于设计简略、优雅、极致人性化的 SDK」的他将以《实时音视频 SDK 设计实际》为主题,畅谈实时音视频 SDK 架构设计的流程、挑战与解决方案。(舒适提醒:流动报名可扫描文末二维码或间接点击报名链接哦~)为帮忙大家更好地理解流动与讲师详情,ECUG 流动组特对讲师进行了简略的采访,现将文字摘录如下: 一、集体篇1、请尝试用三个关键词介绍本人 乐于分享,长期主义,拥抱变动。 2、用一句话介绍本人要分享的内容 一款实时音视频 SDK 是怎么被设计进去的,包含在过程中遇到的挑战以及咱们是怎么解决的。 3、「醉心于设计简略、优雅、极致人性化的 SDK」,起因是什么? SDK 是一款技术服务的门面,它会间接面向咱们的用户。不论这个服务背地的引擎有如许的弱小,用户正确快捷地接入才是前提。 4、对于一款优良的 SDK,应该如何定义? 接口简略,边界清晰,可扩大,可感知。 5、老板会写代码,是坏事还是好事? 老板会写代码,就意味着老板可能从技术层面理解你做的货色,如果碰巧老板的技术是行业内的大神,那就意味着你将会多了一个可能领导你的老师,无论从哪个方面来看,都是坏事。 二、行业篇1、音视频畛域随着技术的倒退,有没有呈现一些「内卷」的景象?有的话是什么? 我并未感觉有内卷景象,咱们输入的产品就是技术和服务,竞争可能促使咱们把产品质量和用户体验做到极致,而这些总是有晋升空间的,对于应用咱们产品的用户来说也是无利的。 2、你认为现阶段音视频技术最外围的问题是什么? 音视频技术相干的难点很多,比方编解码、回声打消、弱网传输等等,但外围解决的是用户体验的问题,观看的画面是否清晰,是否有杂音、卡顿、花屏等景象。如何在内部条件无限的状况下,使得音视频的体验更好,我感觉是现阶段最外围的问题。 3、对于将来音视频技术的利用,你会有哪些期待? 我会期待更加智能化的利用,当初咱们曾经看到音视频和 AI 能力的联合产生出弱小的效应,比方音视频+举荐算法,再比方视频监控 + 内容辨认,可能迅速让一些产品成为行业标杆。所以将来我期待看到更多的音视频与 AI 联合的场景。 4、如何评估七牛云的 RTC SDK ? 通过几次大版本的迭代,当初的 SDK 领有简略可扩大的接口,反对多 track ,大小流,合流转推等特色性能,并且可能实时地感知到线上用户的音视频品质。 看完霍锴的采访,你有哪些问题想要与其进行探讨交换?欢送在文章下方留言,也诚意邀请您报名加入本次线下流动,与讲师进行面对面沟通。点击报名链接即可参加哦~ 「 ECUG Meetup 」是由 ECUG x 七牛云联结主办的沙龙流动,第一期选址杭州西湖区黄姑山路,将以「 2021 音视频技术最佳实际」为主题,从业务场景驱动,围绕音视频技术选型与优化、业务最佳实际、前沿技术利用探索等维度进行分享、互动! 本场流动的讲师来自淘宝、Cocos、Zilliz 以及七牛云,报名到场参会的人群已笼罩音视频畛域上下游及杭州本地知名企业厂商,不便大家结识同行同业。 此外,现场还特设抽奖 + 互动环节,ikbc 机械键盘、Lamy 钢笔、电脑包、七牛云抱枕、技术书籍等等等等等你来领! 扫码增加小助手 输出暗号“我要报名” 就有机会支付「限量收费门票」哦 ...

June 24, 2021 · 1 min · jiezi

关于音视频:AliCloudDenoise-语音增强算法助力实时会议系统进入超清音质时代

近些年,随着实时通信技术的倒退,在线会议逐步成为人们工作中不可或缺的重要办公工具,据不齐全统计,线上会议中约有 75% 为纯语音会议,即无需开启摄像头和屏幕共享性能,此时会议中的语音品质和清晰度对线上会议的体验便至关重要。作者|七琦 审校|泰一 前言在现实生活中,会议所处的环境是极具多样性的,包含宽阔的嘈杂环境、刹时非安稳的键盘敲击声音等,这些对传统的基于信号处理的语音前端加强算法提出了很大的挑战。与此同时随同着数据驱动类算法的疾速倒退,学界 [1] 和工业界 [2,3,4] 逐步涌现出了深度学习类的智能语音加强算法,并获得了较好的成果,AliCloudDenoise 算法在这样的背景下应运而生,借助神经网络卓越的非线性拟合能力,与传统语音加强算法相结合,在一直的迭代优化中,针对实时会议场景下的降噪成果、性能耗费等方面进行了一系列的优化与改良,最终能够在充分保证降噪能力的同时保有极高的语音保真度,为阿里云视频云实时会议零碎提供了卓越的语音会议体验。 语音加强算法的倒退现状语音加强是指洁净语音在现实生活场景中受到来自各种噪声烦扰时,须要通过肯定的办法将噪声滤除,以晋升该段语音的品质和可懂度的技术。过来的几十年间,传统单通道语音加强算法失去了疾速的倒退,次要分为时域办法和频域办法。其中时域办法又能够大抵分为参数滤波法 [5,6] 和信号子空间法 [7],频域办法则包含谱减法、维纳滤波法和基于最小均方误差的语音幅度谱估计办法 [8,9] 等。 传统单通道语音加强办法具备计算量小,可实时在线语音加强的长处,但对非安稳突发性噪声的克制能力较差,比方马路上忽然呈现的汽车鸣笛声等,同时传统算法加强后会有很多残留噪声,这些噪声会导致主观听感差,甚至影响语音信息传播的可懂度。从算法的数学实践推导角度来说,传统算法还存在解析解求解过程中假如过多的问题,这使得算法的成果存在显著下限,难以适应复杂多变的理论场景。自 2016 年起,深度学习类办法显著晋升了许多监督学习工作的性能,如图像分类 [10],手写辨认 [11],主动语音辨认 [12],语言建模 [13] 和机器翻译 [14] 等,在语音加强工作中,也呈现了很多深度学习类的办法。 图一 传统单通道语音加强零碎的经典算法流程图 基于深度学习类的语音加强算法依据训练指标的不同大抵可分为以下四类: • 基于传统信号处理的混合类语音加强算法(Hybrid method)这类算法多将传统基于信号处理的语音加强算法中的一个或多个子模块由神经网络代替,个别状况下不会扭转算法的整体解决流程,典型代表如 Rnnoise[15]。 • 基于时频掩模近似的语音加强算法(Mask_based method)这类算法通过训练神经网络来预测时频掩模,并将预测的时频掩模利用于输出噪声的频谱来重构污浊语音信号。 罕用的时频掩模包含 IRM[16],PSM[17], cIRM[18] 等,训练过程中的误差函数如下式所示: • 基于特色映射的语音加强算法(Mapping_based method)这类算法通过训练神经网络来实现特色的间接映射,罕用的特色包含幅度频谱、对数功率频谱和复数频谱等,训练过程中的误差函数如下式所示: • 基于端到端的语音加强算法(End-to-end method)这类算法将数据驱动的思维施展到了极致,在数据集散布正当的前提下,抛却频域变换,间接从时域语音信号进行端到端的数值映射,是近两年宽泛沉闷在学术界的热门钻研方向之一。 AliCloudDenoise 语音加强算法一、算法原理在综合思考业务应用场景,对降噪成果、性能开销、实时性等诸多因素衡量后,AliCloudDenoise 语音加强算法采纳了 Hybrid 的办法,将带噪语音中噪声能量和指标人声能量的比值作为拟合指标,进而利用传统信号处理中的增益预计器如最小均方误差短时频谱幅度 (MMSE-STSA) 预计器,求得频域上的去噪增益,最初经逆变换失去加强后的时域语音信号。在网络结构的抉择上,兼顾实时性和功耗,舍弃了 RNN 类构造而抉择了 TCN 网络,根本网络结构如下图所示: 二、实时会议场景下的算法优化1、散会时旁边人多很吵怎么办?问题背景在实时会议场景中,有一类较为常见的背景噪声是 Babble Noise,即多个谈话者的交谈声组成的背景噪声,此类噪声不仅仅是非安稳的,而且和语音加强算法的指标语音成分类似,导致在对这类噪声的克制过程中算法解决的难度增大。以下列举了一个具体的实例: 问题剖析与改良计划通过对数十小时含有 Babble Noise 的办公室场景音频进行剖析,同时联合人类的语音发声机制,发现这类噪声具备类长时安稳存在个性,家喻户晓,在语音加强算法中,上下文信息(contextual information)对算法成果有着十分重要的影响,所以针对 Babble Noise 这种对上下文信息更加敏感的噪声类型,AliCloudDenoise 算法通过空洞卷积(dilated convolutions)系统性地聚合模型中的要害阶段性特色,显式的增大感触野,同时额定的交融了门控机制(gating mechanisms),使得改良后的模型对 Babble Noise 的解决成果有了显著的改善。下图展现了改良前(TCN)与改良后(GaTCN)的要害模型局部的比照图。 ...

June 24, 2021 · 4 min · jiezi

关于音视频:Zilliz-陈室余女性的独特洞察和视角可能为开源发现新机遇-|-ECUG-Meetup-讲师专访

6月26日下午, ECUG x 七牛云将在杭州联结主办「 ECUG Meetup 第 1 期」流动,来自 Zilliz 的资深数据工程师陈室余将以《音视频的相似性检索与举荐》为主题进行分享,从利用场景与解决方案登程,探讨如何通过开源向量数据库 Milvus 与 AI 技术轻松实现音视频的剖析与举荐。(舒适提醒:流动报名可扫描文末二维码或间接点击报名链接哦~) 为帮忙大家更好地理解流动与讲师详情,ECUG 流动组特对讲师进行了简略的采访,现将文字摘录如下: 一、集体篇1、请尝试用三个关键词介绍本人 开源互助——踊跃激情地在开源社区为用户提供帮忙与反对; 拥抱变动——一直学习新事物,承受新挑战; 程序媛——每天做着本人喜爱的编程工作。 2、用一句话介绍本人要分享的内容 联合 AI 技术与开源向量数据库 Milvus,能够轻松实现音视频的剖析与举荐。 3、Zilliz 公司的 Milvus 作为开源畛域的一个明星产品,你认为最大的劣势是什么? 简略易用。Milvus 提供 Docker 部署和多种 API,让用户以最小的老本疾速搭建本人的最小化产品。 二、技术篇1、音视频畛域随着技术的倒退,有没有呈现一些「内卷」的景象?有的话是什么? 目前很多畛域都开始做视频,从最早的娱乐和教育,到电商和技术直播,那么不同的畛域又会有不同的需要,就须要设计不同的零碎来适配,呈现了越来越多的音视频平台进行竞争。 2、你认为现阶段音视频技术最外围的问题是什么? 音视频数据每时每刻都在生成,外围问题就在于如何实时处理这些宏大的数据。 3、对于将来音视频技术的利用,你会有哪些期待? 心愿将来的音视频解决能够更加智能,比方举荐、语音解决等更加个性化。 三、行业篇1、是否谈一下你对开源的了解? 开源须要更多利他主义,把本人的产品开源进来帮忙到他人,那会是一件十分有意义的事。另外开源也是是缩小反复造轮子的重要伎俩,对于一些比拟根底的底层技术,如果各家企业都各自闭门研发,必然造成反复投入以及后续市场的恶性竞争。咱们冀望能够发动并保护一个受世界宽泛认可的开源我的项目。 2、开源带给你最大的播种是什么? 开源让我意识了很多优良的我的项目,像 Java、Hadoop、Spark 等一系列我的项目都让咱们从中受害。同时,开源也让我意识了很多气味相投的小伙伴,他们来自世界各地,咱们通过网络探讨开源我的项目,分享各自的想法,一起开发并欠缺我的项目。 3、随着社会的倒退,性别标签正在逐步被弱化。您认为对于开发者畛域来说,女性成员的退出会带来哪些变动与不同? 在我看来每个人都有本人的特点和价值,女性可能对一些畛域有独特洞察和视角,能够为开源发现新机遇。女性的退出也能够让开源畛域更加多元化,比方咱们公司有30%以上的女性,都在本人的岗位施展价值,有的编程,有的推广开源社区,有的为公司招募人才。 看完陈室余的采访,你有哪些问题想要与其进行探讨交换? 欢送在文章下方留言,也诚意邀请您报名加入本次线下流动,与讲师进行面对面沟通。 点击报名链接即可到达报名页面哦~ 「 ECUG Meetup 」是由 ECUG x 七牛云联结主办的沙龙流动,第一期选址杭州西湖区黄姑山路,将以「 2021 音视频技术最佳实际」为主题,从业务场景驱动,围绕音视频技术选型与优化、业务最佳实际、前沿技术利用探索等维度进行分享、互动! 本场流动的讲师来自淘宝、Cocos、Zilliz 以及七牛云,报名到场参会的人群已笼罩音视频畛域上下游及杭州本地知名企业厂商,不便大家结识同行同业。 此外,现场还特设抽奖 + 互动环节,ikbc 机械键盘、Lamy 钢笔、电脑包、七牛云抱枕、技术书籍等等等等等你来领! ...

June 18, 2021 · 1 min · jiezi

关于音视频:Cocos-大表姐所有技术的本质都是数学问题丨ECUG-Meetup-讲师专访

6月26日13:30,Cocos 引擎布道师负责人李阳(花名:大表姐)将在由 ECUG x 七牛云联结主办的「 ECUG Meetup 第 1 期 · 杭州站」流动中,以《 Cocos 引擎中的音视频利用》为主题进行分享。(舒适提醒:流动报名可扫描文末二维码或间接点击报名链接哦~) 为帮忙大家更好地理解流动与讲师详情,ECUG 流动组特对讲师进行了简略的采访,现将文字摘录如下: 一、集体篇1、请尝试用三个关键词介绍本人 自律 冲破 慎独 2、用一句话介绍本人要分享的内容 我会联合 Cocos 引擎解说音视频在游戏中的利用,并分享最近很火的视频在教育编辑器内如何UI交互的内容。 3、花名「大表姐」的由来? 我也不晓得为什么,刚刚程序出道时大家就这么叫了。不过,我确实很喜爱詹妮佛·劳伦斯。 4、最喜爱玩的一款游戏是什么?认为本人做过最好的游戏是哪一款?为什么? 喜爱玩的就是比拟雅致的王者光荣,我喜爱玩猪八戒,肉到让人失望,啊哈哈哈哈……做过最好的是捕鱼达人系列吧,过后还是 Cocos2d-x 和 C++ 联合的开发模式,毕竟是一款景象级的游戏,玩家也超过了一亿,还是感觉很骄傲的。 二、技术篇1、音视频畛域随着技术的倒退,有没有呈现一些「内卷」的景象?有的话是什么? 因为我所在的是游戏引擎行业,对音视频技术的应用大多是应用层,自身不太存在内卷的状况。但我认为“内卷”的实质是抢夺,所以心愿行业可能以技术为根底,将更多的工夫和精力投入在创作内容上,从而进一步拉动其余多个畛域的内容聚合。 2、你认为现阶段音视频技术最外围的问题是什么? 其实我始终认为和计算机相关的都能够实质上归于数学。音视频技术,从采集的原始数据,编码,压缩,封装,通过传输协定发送,客户端将音视频数据拆散提取进去,解码和渲染到屏幕上。这整个过程都是在做一个还原场景的事件,而是否实在地模仿最实在的场景,实质上也是算法的问题,归根于数学。 3、对于将来音视频技术的利用,你会有哪些期待? 对于游戏来说,期待在音视频播放过程中和用户产生更多的互动行为。目前音视频虽说有一些社交行为(留言、刷礼物等),但实质上仍是单向流传的模式。所以心愿在这个过程中用户能够更多地参加进来,通过智能辨认用户行为,产生不同反馈。 三、行业篇1、作为一个女生,在男性占据绝大多数的程序员行业内,有没有一些特地的中央? 我作为一名女性开发者,并没有一堆人围着帮我解决问题的状况。在这个行业大家还是靠能力来失去认可的,毕竟大家须要的是解决问题和实现产品的能力。 2、随着社会的倒退,性别标签正在逐步被弱化。您认为对于开发者畛域来说,女性成员的退出会带来哪些变动与不同? 不论是开发者不论是开发者畛域也好,或者是老师护士这些公众认为女性为主的行业也好,都很容易被标签化,就如同“格子衫、双肩包、黑框眼镜”是程序员的标签一样。事实上在开发者畛域,女性和男性没有任何区别,死磕技术、强势、雷厉风行,这些都是人的性情、岗位需要决定的,而非性别。近年来,开发者畛域的女生比例多了起来,我记得 2013 年那段时间,一个组就我一个女生,会有一种四周全是男性而被异化的状况。当初身边的女生同行多了起来,大家在沟通交流下面会更为谐和。 看完李阳的采访,你有哪些问题想要与其进行探讨交换?欢送在文章下方留言,也诚意邀请您报名加入本次线下流动,与讲师进行面对面沟通。点击报名链接即可到达报名页面哦~ 「 ECUG Meetup 」是由 ECUG x 七牛云联结主办的沙龙流动,第一期选址杭州西湖区黄姑山路,将以「 2021 音视频技术最佳实际」为主题,从业务场景驱动,围绕音视频技术选型与优化、业务最佳实际、前沿技术利用探索等维度进行分享、互动! 本场流动的讲师来自淘宝、Cocos、Zilliz 以及七牛云,报名到场参会的人群已笼罩音视频畛域上下游及杭州本地知名企业厂商,不便大家结识同行同业。 此外,现场还特设抽奖 + 互动环节,ikbc 机械键盘、Lamy 钢笔、电脑包、七牛云抱枕、技术书籍等等等等等你来领! 扫码增加小助手,输出暗号“我要报名”,就有机会支付「限量收费门票」哦! 也可间接点击报名链接,理解更多流动详情+报名~

June 17, 2021 · 1 min · jiezi

关于音视频:融云视角沉浸式音频与通讯技术未来趋势

回顾互联网倒退历程,从 PC 局域网到挪动互联网,互联网应用的沉迷感逐渐晋升,虚构与事实的间隔也逐步放大。利用沉迷式音频与通信技术将来将会很大水平晋升用户的体验感,而在虚构与事实的元宇宙中,对沉迷感、参与度、永续性等方面都有很高的要求,因而将会由许多独立工具、平台、基础设施、协定等来反对其运行。随着 AR、VR、5G、云计算等技术成熟度晋升,基于沉迷式音频的通信技术在元宇宙无望逐渐从概念走向事实。 本文将和业内搭档一起摸索元宇宙技术倒退对通信行业带来的影响,将来沉迷式音频的发展趋势以及通信技术在 VR、AR、AI 行业的利用。 元宇宙概念简述元宇宙(Metaverse)是指打造一个与现实生活平行的、体验简直无差别的虚拟世界。人类能够利用虚构身份在虚拟世界工作、社交互动、娱乐游戏,甚至交易交易。总结进去就是,在元宇宙中,你能够想什么就有什么,无边无际的想象力给予你有限的自在。 Metaverse 元宇宙所发明的独立于事实世界的虚构数字第二世界,使用户能以数字身份自在生存。VR、AR、AI 作为 Metaverse 的技术根底将迎来高速增长期。虚拟现实行业 2020 年寰球市场规模约为 900 亿元人民币,预计 2020-2024 年均增长率约为 54%。据中国信通院预测,2021 年开始寰球虚构设施出货量将减速,预计 2024 年可达 7500 万台。(数据起源:天风证券《Metaverse钻研报告》)随着 VR 产业链的逐步完善,VR 对行业的赋能会展现出弱小的飞轮效应。 那么咱们怎么样能力从事实世界,逐步进入到元宇宙世界中去呢? 真实感的维度如果把元宇宙场景中,用户体验到的真实感划分为两个维度:“沉迷感”和“自由度”。两个轴的终点,则是原生感知事实,例如正在浏览这篇文章的你。沉迷和自在的深度,独特决定了元宇宙中的用户体验是否足够实在。 真实感的等级 Lv1:从原生感知初步向虚拟世界迈进的阶段Lv2:让大脑感觉局部实在的虚拟世界Lv3:齐全骗过大脑的全真虚拟世界Max:和原生世界深度雷同的虚拟世界 元宇宙现阶段发展趋势现阶段元宇宙概念的产业链,例如互动体验、人机交互等,大部分能力范畴在 Lv1-Lv2 之间,仅有少部分尖端企业向 Lv3 迈进。将来阶段如何实现 Max 的指标,是否能真正实现,目前还无奈得悉。 Lv1-Lv2 范畴的产业链已日渐成熟,目前曾经实现 3D 体感电影、凋谢沙盒游戏、VR、AR、MR 游戏等利用。 如果说 Lv2 阶段的用户体验,是由某几个沉迷或自在因素沉积而成的“半实在”体验,那么降级到 Lv3 阶段的“全实在”体验,能够说是质的飞跃。“沉迷”和"自在"必须做到足够的深度,相辅相成。数字化的视觉和听觉感知体验是否能够齐全骗过咱们的大脑?3D 引擎是否能提供足够的自在体验?AI 是否能做到永续性、自成长?网络传输是否可实现无提早?只有任何一个因素存在缺点,就不可能真正实现“全实在”的用户体验。可见从“半实在”到“全实在”,实现难度会陡增。 到 Lv3 之后,元宇宙下一个阶段,就是实现终极目标,让人们的意识永生在虚拟世界。影响这一指标实现的因素,除硬件、软件、通信等科技因素之外,还波及到生物学和医学领域。是否能真正实现,目前来看仍是未知。 头部厂商的停顿 1.Facebook2020 年 9 月,Facebook Connect 2020 大会上,Facebook 公布了 AR/VR 十五大重要战略规划。会上颁布的一系列 AR/VR 信息,涵盖最新硬件产品、软件产品、解决方案、开发者服务、前沿技术钻研等。 其中 VR 头显 Oculus Quest 2 依附平台提供的游戏和软件反对,曾经成为目前市场上支流的 VR 头部穿戴设施。 ...

June 15, 2021 · 1 min · jiezi

关于音视频:揭秘视频千倍压缩背后的技术原理之预测技术

前言随着5G的成熟和宽泛商用,带宽曾经越来越高,传输视频变得更加容易。设施特地是挪动设施算力的晋升、存储容量的晋升,使得视频技术的利用越来越宽泛,无论是流媒体、泛娱乐、实时通信,视频都带给了用户更加丰盛的体验。 视频相干的技术,特地是视频压缩,因其专业性,深刻开发的门槛较高。具体到视频实时通信场景,视频压缩技术面临更严厉的挑战,因为实时通信场景下,对时延要求十分高,对设施适配的要求也十分高,对带宽适应的要求也十分高,开发一款满足实时通信要求的编解码器,难度也很高。之前的文章中,咱们曾经在《深入浅出了解视频编解码技术》一文中简要介绍了视频编解码根本框架,明天咱们将深刻分析其中的预测模块,便于大家更好地了解视频编解码技术。 01 色彩空间 开始进入主题之前,先简略看一下视频是如何在计算机中进行表白的。视频是由一系列图片依照工夫顺序排列而成,每一张图片为一帧。每一帧能够了解为一个二维矩阵,矩阵的每个元素为一个像素。一个像素通常由三个色彩进行表白,例如用RGB色彩空间示意时,每一个像素由三个色彩重量组成。每一个色彩重量用1个字节来表白,其取值范畴就是0~255。编码中罕用的YUV格局与之相似,这里不作开展。 图一 以1280x720@60fps的视频序列为例,十秒钟的视频有128072036010 = 1.6GB,如此大量的数据,无论是存储还是传输,都面临微小的挑战。视频压缩或者编码的目标,也是为了保障视频品质的前提下,将视频减小,以利于传输和存储。同时,为了能正确还原视频,须要将其解码。从最早的H.261开始,视频编解码的框架都采纳了这一构造,如图所示。次要的模块分为帧内/帧间预测、(反)变换、(反)量化、熵编码、环内滤波。一帧视频数据,首先被宰割成一系列的方块,依照从左到右从上到下的形式,一一进行解决,最初失去码流。 图二 02 帧内预测 视频数据被划分成方块之后,相邻的方块的像素,以及方块内的像素,色彩往往是逐步变动的,他们之间有比拟强的有相似性。这种相似性,就是空间冗余。既然存在冗余,就能够用更少的数据量来表白这样的特色。比方,先传输第一个像素的值,再传输第二个像素绝对于第一个像素的变动值,这个变动值往往取值范畴变小了许多,原来要8个bit来表白的像素值,可能只须要少于8个bit就足够了。同样的情理,以像素块为根本单位,也能够进行相似的“差分”操作。咱们从示例图中,来更加直观地感受一下这样的相似性。 图三 如图中所标出的两个8x8的块,其亮度重量(Y)沿着“左上到右下”的方向,具备连续性,变动不大。如果咱们设计某种特定的“模式”,使其利用右边的块来“预测”左边的块,那么“原始像素”减去“预测像素”就能够缩小传输所须要的数据量,同时将该“模式”写入最终的码流,解码器便能够利用左侧的块来“重建”右侧的块。极其一点讲,如果左侧的块的像素值通过肯定的运算能够齐全和右侧的块雷同,那么编码器只有用一个“模式”的代价,传输右侧的块。当然,视频中的纹理多种多样,繁多的模式很难对所有的纹理都实用,因而规范中也设计了多种多样的帧内预测模式,以充分利用像素间的相关性,达到压缩的目标。例如下图 (From Vcodex)所示的H.264中9种帧内预测方向。以模式0(竖直预测)为例,上方块的每个像素值(重建)各复制一列,失去帧内预测值。其它各种模式也采纳相似的办法,不过,生成预测值的形式稍有不同。有这么多的模式,就产生了一个问题,对于一个块而言,咱们应该采纳哪种模式来进行编码呢?最佳的抉择形式,就是遍历所有的模式进行尝试,计算其编码的所需的比特数和产生的品质损失,即率失真优化,这样显著非常复杂,因此也有很多种其它的形式来推断哪种模式更好,例如基于SATD或者边缘检测等。 从H.264的9种预测模式,到AV1的56种帧内方向预测模式,越来越多的模式也是为了更加精准地预测未编码的块,然而模式的减少,一方面减少了传输模式的码率开销,另一方面,从如此重多的模式当选一个最优的模式来编码,使其能达到更高的压缩比,这对编码器的设计和实现也提出了更高的要求。 图四03 帧间预测 以下5张图片是一段视频的前5帧,能够看出,图片中只有Mario和砖块在静止,其余的场景大多是类似的,这种相似性就称之为工夫冗余。编码的时候,咱们先将第一帧图片通过前文所述的帧内预测形式进行编码传输,再将后续帧的Mario、砖块的静止方向进行传输,解码的时候,就能够将静止信息和第一帧一起来合成后续的帧,这样就大大减少了传输所需的bit数。这种利用工夫冗余来进行压缩的技术,就是静止弥补技术。该技术早在H.261规范中,就曾经被采纳。 图五 细心地读者可能曾经发现,Mario和砖块这样的物体怎么形容,能力让它仅凭静止信息就能残缺地出现进去?其实视频编码中并不需要晓得静止的物体的形态,而是将整帧图像划分成像素块,每个像素块应用一个静止信息。即基于块的静止弥补。下图中红色圈出的红色箭头即编码砖块和Mario时的静止信息,它们都指向了前一帧中所在的地位。Mario和砖块都有两个箭头,阐明它们都被划分在了两个块中,每一个块都有独自的静止信息。这些静止信息就是静止矢量。静止矢量有程度和竖直两个重量,代表是的一个块绝对于其参考帧的地位变动。参考帧就是曾经编码过的某一(多)个帧。 图六当然,传输静止矢量自身就要占用很多 bit,为了进步静止矢量的传输效率,一方面,能够尽可能得将块划分变大,共用一个静止矢量,因为平坦区域或者较大的物体,他们的静止可能是比拟统一的,从 H.264 开始,可变块大小的静止弥补技术被宽泛采纳;另一方面,相邻的块之间的静止往往也有比拟高的相似性,其静止矢量也有较高的相似性,静止矢量自身也能够依据相邻的块静止矢量来进行预测,即静止矢量预测技术;最初,静止矢量在表白物体静止的时候,有精度的取舍。像素是离散化的表白,事实中物体的静止显然不是以像素为单位进行静止的,为了准确地表白物体的静止,须要抉择适合的精度来定义静止矢量。各视频编解码规范都定义了静止矢量的精度,静止矢量精度越高,越能准确地表白静止,然而代价就是传输静止矢量须要破费更多的bit。H.261中静止矢量是以整像素为精度的,H.264中静止矢量是以四分之一像素为精度的,AV1中还减少了八分之一精度。个别状况,工夫上越近的帧,它们之间的相似性越高,也有例外,例如往复运动的场景等,可能相隔几帧,甚至更远的帧,会有更高的类似度。为了充分利用曾经编码过的帧来进步静止弥补的准确度,从H.264开始引入了多参考帧技术,即,一个块能够从曾经编码过的很多个参考帧中进行静止匹配,将匹配的帧索引和静止矢量信息都进行传输。 那么如何失去一个块的静止信息呢?最奢侈的想法就是,将一个块,在其参考帧中,一一地位进行匹配查看,匹配度最高的,就是最终的静止矢量。匹配度,罕用的有SAD(Sum of Absolute Difference)、SSD(Sum of Squared Difference)等。一一地位进行匹配度查看,即常说的全搜寻静止预计,其计算复杂度可想而知是十分高的。为了放慢静止预计,咱们能够缩小搜寻的地位数,相似的有很多算法,罕用的如钻石搜寻、六边形搜寻、非对称十字型多层次六边形格点搜索算法等。以钻石搜寻为例,如图所示,以起始的蓝色点为核心的9个匹配地位,别离计算这9个地位的SAD,如果SAD最小的是核心地位,下一步搜寻中心点更近的四周4个绿色点的SAD,抉择其中SAD最小的地位,持续放大范畴进行搜寻;如果第一步中SAD最小的点不在核心,那么以该地位为核心,减少褐色的5或者3个点,持续计算SAD,如此迭代,直到找到最佳匹配地位。 图七 编码器在实现时,可依据理论的利用场景,对搜索算法进行抉择。例如,在实时通信场景下,计算复杂度是绝对无限的,静止预计模块要抉择计算量较小的算法,以均衡复杂度和编码效率。当然,静止预计与静止弥补的复杂度还与块的大小,参考帧的个数,亚像素的计算等无关,在此不再深刻开展。 04 总结 本文介绍的预测技术,充分利用了视频信号空间上和工夫上的相关性,通过多种设计精美的预测模式,达到了去除冗余的目标,这是视频压缩高达千倍比例的要害之一。纵观视频编解码技术的倒退历史,预测模式越来越多,预测的精确度越来越高,带来的压缩比也越来越高。如何疾速高效地应用这些预测模式,也必然成为设计实现的重中之重,成为H.265/H.266/AV1这些新规范施展其高效压缩性能的要害。关注拍乐云Pano,咱们将在前面的文章中为大家分享《视频编解码系列》的更多技术干货。 图片出处: 图一: https://github.com/leandromor... 图四: H.264/AVC Intra Prediction

June 10, 2021 · 1 min · jiezi

关于音视频:HiHarmonyOS融云全系产品已成功适配鸿蒙-OS-20

June 10, 2021 · 0 min · jiezi

关于音视频:拍乐云运维专家受邀QECon大会畅谈多云环境伸缩实践-拍乐云Pano

5月28日-29日, QECon寰球软件品质&效力大会在深圳万丽酒店圆满闭幕。本届QECon大会聚焦“智能、云原生、协同提效、业务价值” 等主题词,在大会主场的宗旨演讲和15个专场的主题分享中失去详尽、全面的诠释。拍乐云作为业内技术当先的音视频云服务商在云原生、DevOps方面有着深厚的技术积攒,运维专家&负责人毛立平受邀加入本次大会。 明天咱们处在一个新时代——数字化时代,万物互联,技术突飞猛进,云原生、智能、大数据、区块链等技术被软件产品和研发广泛应用,促成业务价值链重构。同时,软件系统的复杂性、不确定性也一劳永逸,给研发和运维带来微小的挑战。为此,咱们更乐意采纳麻利、DevOps开发模式,疾速迭代,继续集成,继续交付;咱们也更加关注效力,开源协同,数据驱动效力,欠缺工具链,减速业务价值的交付。 拍乐云Pano 运维专家&负责人毛立平在「云原生品质」专题论坛中给大家带来了一场对于「多云环境弹性伸缩实际」的精彩分享,引起了在场听众的积极响应和深刻思考。以下为局部演讲实录。 1多云的劣势和挑战 对于一个实时互动的音视频服务,拍乐云须要在寰球范畴内做到端到端通信400ms以内。因而咱们采纳了分布式的部署架构,在大区自建数据中心,同时利用私有云的能力作为补充,将服务部署到不同云厂商的不同地区,达到更好的网络覆盖成果。对于第三方云厂商也无奈笼罩的区域,咱们通过在边缘机房部署 Pop 节点的形式进行减速。通过大区自建数据中心+多云+ Pop 节点的混合计划,咱们实现了寰球 200+ 国家及地区的网络覆盖和寰球用户的就近接入。 咱们将服务部署在多云环境,会有以下劣势: 利用不同厂商的网络,能够取得更好的网络覆盖; 能够取得更好的弹性,寰球不同云不同区域随时进行扩容缩容; 鸡蛋不放在一个篮子,能够取得更好的服务可用性,繁多云厂商呈现不可用时,也不会影响整体服务。 然而,将服务运行在多云环境时也会面临一些挑战: 镜像一致性:不同云厂商的镜像会不统一, 同一个云厂商的镜像在不同时刻,也会有不统一的状况; 拓扑一致性:不同云上基础设施部署拓扑也存在不统一的状况; 性能一致性:不同云的性能/性能/网络体现存在差别; 容量一致性:不同云上如何定义一个对立容量规范,如何进行扩容/缩容。 2多云的解决办法 面对这些挑战,拍乐云采纳了以下解决思路: 标准化:自定义镜像制作形式,对立不同云的镜像。自定义部署拓扑构造,对立不同云的部署拓扑; 分层化:拆散基础设施和利用部署的过程; 代码化:将基础设施代码化,实现IaC(Infrastructure as Code),同时将利用部署代码化,全脚本化部署利用; 自动化:定义服务容量,跨云伸缩规定配合调度规定实现主动扩容缩容。 在评估服务容量时,大多数的厂家应用的是 CPU、带宽这类零碎参数来决策是否进行服务扩容/缩容。但这会容易呈现一些问题,比方:CPU 使用率不是很高时,服务容量可能曾经有余了,这种状况下,依据零碎指标进行扩容缩容,容易呈现问题。 拍乐云应用的是应用层的容量指标来形容,所有服务对立应用 0-1000 示意容量。每个应用服务都会裸露这个容量指标,同时,咱们通过比照这个容量指标和零碎指标的差别,继续对容量指标的精度进行修改。等跑了一段时间当前,这个容量指标就能比零碎指标更准确,符合实际。 3多云的成果和将来工作 目前拍乐云能做到在几分钟内,对全网实现寰球数百个服务器并发扩容/缩容,轻松应答突发流量。将来,咱们将对历史容量趋势进行剖析,优化扩容/缩容的步长,进一步晋升扩容/缩容的精度。作为一家全球化的实时音视频云服务商,咱们将以数据为驱动,深耕 DevOps 畛域,夯实底层基础设施,为企业和开发者提供更加优质的音视频体验。

June 7, 2021 · 1 min · jiezi

关于音视频:融云技术超大规模并发下自定义属性的设置与分发

一. 自定义属性介绍和利用场景 在挪动互联网高速倒退的新时代,IM 即时通讯失去了疾速的倒退。IM 中除了传统的图文聊天,在线秀场、在线教育、直播带货、游戏互动等场景利用也越来越宽泛。特地是一些一线主播的直播中,直播间动辄几万甚至几十万上百万人同时观看,这对 IM 的通信并发能力提出了更高的要求。 融云作为 IM 即时通讯和音视频通信云服务的代表,提供了直播聊天室 SDK 和音视频直播 SDK。而在提供这些根底性能的时候,业务层可能也须要设置一些本人的属性,比方在语音直播聊天室场景的会场属性同步,主播麦位信息、角色治理等等,亦或者狼人杀等卡牌类游戏场景中记录用户的角色和牌局状态等。这些自定义属性都能够丰盛整个 IM 的业务状态。 在本篇文章中我重点介绍以聊天室为背景的超大并发规模下,是如何实现这些自定义属性的设置以及散发的。 二. 海量用户下面临的技术挑战 聊天室和一般的 IM 群相比最大的不同点在于它是一个虚构的组织,聊天室是无界的,所有的人都能够随便的进出聊天室;而群更像一个房间,它是一个有界的、有下限的私密组织。而随着直播行业的蓬勃发展和观看直播人数的与日剧增,直播房间的聊天室更容易呈现那种超高并发场景,例如一线主播直播间的聊天室。 自定义属性在进行了设置后,须要及时的将这些属性同步到聊天室中的各个端上。在这个过程中最大的挑战是在散发上。因为如果聊天室人数巨多,而且很多场景自定义属性是具备时效性的,所以及时的将自定义属性同步到各端就很考验服务的高并发场景下的散发能力了。 三. 高并发下自定义属性设置与散发实现 在分布式系统架构中,为了对立聊天室的行为,咱们会利用一致性 hash 将同一个聊天室的所有信令汇聚到一个实例上。这样做是有肯定益处的,比方能晋升服务的缓存命中率,像聊天室人员进出黑/白名单设置和判断等都能够利用内存中的缓存,不必每次都拜访第三方缓存,从而进步了聊天室的响应速度。然而这样带来的问题就是,如果聊天室人数过大,聊天室的散发能力会是零碎的瓶颈,而且一旦单台主机下发能力达到下限,是无奈通过扩容来解决问题的,因为不管怎么扩容,一个聊天室的所有信令还是会汇聚到这个实例中。 为了晋升服务的散发能力,咱们独立出一套独自的散发服务(聊天室音讯服务),具体如下图所示: 在这套架构零碎中,咱们将聊天室零碎分为聊天室服务以及聊天室音讯服务,聊天室服务的作用仍然是接管聊天室相干的所有上行信令,比方人员进出,自定义属性设置等等。而聊天室音讯服务更专一聊天室音讯以及自定义属性等的散发。 用户在退出聊天室后,须要依据用户本身的 ID 进行一致性 hash 来算出须要落在哪个聊天室音讯服务中,并进行退出。这样一个聊天室的用户就会被均匀扩散到了聊天室音讯服务中。这样做也解决了零碎遇到压力后不能扩容的问题。在自定义属性同步到聊天室音讯服务上后,散发节点须要将属性搁置到内存中,而后给以后节点的所属用户发送一个告诉拉取的信令,客户端在收到告诉拉取信令后进行自定义属性的拉取。 四. 自定义属性的内存存储和客户端疾速拉取 在聊天室音讯服务接管到自定义属性变更申请时,会将这份数据保留到全量属性汇合里,这个汇合里存的是所有的自定义属性汇合,如果这份数据被 LRU 淘汰掉或者服务重启的话,会从第三方缓存中从新构建一份数据进去。 内存中的全量数据,比拟适宜于刚退出聊天室的人,他们退出聊天室后间接拉取这些全量数据即可。然而如果曾经在聊天室了也曾经拉取过全量属性的话,这时聊天室再设置了新的自定义属性或者删除了某一个自定义属性的话,如果客户端想晓得方才的自定义属性的行为,就须要对客户端的全量自定义属性与服务器端自定义属性进行比对。不论比对行为是放在服务器端还是放在客户端都会减少肯定的计算压力。为了解决增量数据的同步,咱们构建了一份属性变更记录的汇合,具体如图所示: 属性变更记录采纳的是一个有序的 map 汇合 .key 为变更工夫戳,value 里存变更的类型以及自定义属性内容,变更的类型次要为设置和删除。这个有序的 map 提供了这段时间内所有的自定义属性的动作,客户端在收到自定义属性变更拉取的告诉后,带着本人本地最大自定义属性的工夫戳上来拉取,例如图中场景,客户端传的如果是工夫戳 6,则会拉取到工夫戳为 7 和工夫戳为 8 的两条记录。客户端拉取到增量的内容后在本地进行回放,而后对本人本地的内容进行相干的操作即可。 五. 结束语 文章大体解析了融云聊天室的基础架构以及在此架构下,如何做到了超大规模并发下的自定义属性的设置和散发。而随着互联网的高速倒退,自定义属性的设置利用会越来越宽泛,而并发规模或者会持续晋升,届时咱们的架构也会迭代,持续为客户提供低延时高牢靠的服务。

June 4, 2021 · 1 min · jiezi

关于音视频:拍乐云推出业内首个线上美术教学音视频方案打造极致互动体验

在线教育因为其上课的工夫地点便捷、名师资源共享和弱小的教研能力,取得了越来越多学生和家长的青眼,教学生如何发明美的美术教育也被滚滚浪潮推向了线上。但无奈面授,笔墨丹青如何一线牵?线上美术教学效果能不能媲美甚至超过线下? 近日,拍乐云PANO 在 QCon 北京寰球软件开发者大会上发表推出业内首个成熟的「线上美术教学音视频计划」,打造极致互动体验,让学生和老师都能在多姿多彩的线上美术教学中享受这份沉迷感。本文旨在探讨拍乐云作为实时互动底层技术 PaaS 厂商对美术教学这件事赋予的当初和将来。 作为底层技术厂商,咱们反过来思考,一个将来的美术课,咱们心愿它是怎么的?咱们当初又能做到哪些?或者就能离答案更近一步。 01 将来的美术课是怎么的? Amy 是生存在美国加州的一位11岁小女孩,从小就喜爱画画,作为华人第二代移民,父母都心愿她能多学习一些中国的传统文化,因而给她报了线上美术课,跟着杭州的 Helen 老师学习中国水墨画。「突破工夫和空间」 又到了Amy 最期待的画画工夫了,她走进画室,唤醒虚构课堂 APP,光影盘绕间, Helen 老师正在摇曳的竹林间微笑着向她打招呼。「虚拟现实」 明天要画的是竹子,Helen 老师关上互动白板,分享 PPT 课件,联合课件的超高清画作和视频,解说各种竹子的状态和画法,Amy 学习起来十分活泼直观。「互动白板、高清多媒体课件」 接下来的绘画练习,Helen 老师带着 Amy 一起画画。Helen 一边画一边解说要点,Amy 看着老师和画纸,认真观摩老师的绘画手法和画纸构图。Amy 画时,Helen 老师站在她身侧通知她构图的要点。随着 Helen 老师手指的点画,虚构的线条在画纸和远方的竹林上浮现,这让 Amy 立即体会了老师的意思。「实时标注、超低提早」 Amy 明天的上课进度让 Helen 老师十分称心,Helen 老师在 Amy 背后展现更多优良的名画,扩大这堂课的内容深度。 课程完结,这堂课的内容全副被保留下来,Amy 随时能够从新回顾任何一段内容。「课程回放」 02 当初咱们能做到什么? 当初说将来已来,可能略早,因为虚拟现实还没有走进公众,然而除了虚拟现实,咱们都曾经实现了! 突破工夫和空间 不用浪费路上的工夫,抉择最喜爱的老师,预约工夫,在家关上挪动设施,安排好画板就能开始一堂发明美的美术课。 还原实在 设施反对开启多个摄像头,同时看到人像和画纸细节;反对改正摄像头画面角度;反对1080P高清还原画作;反对虚构背景替换。关注细节,还原每一处实在的教学场景。 实时标注、超低提早 端到端最低68毫秒时延的实时音视频交换,反对在视频画面上应用画笔实时标注,让老师和学生沟通零距离。 互动白板、高清多媒体课件 白板反对高清多媒体课件(图片、视频、PPT等),老师能够随时调出课件,实时展现、同步播放。 课程回放 课程完结后依据配置的录制布局,主动生成云端课堂回放视频,便于学生回顾。 03 业内首个成熟的 美术教学音视频计划 用户体验是在线教育产品的外围竞争力之一,也是在不足评估规范的素质教育赛道里绝对明确的评估形式。教学过程的舒适感,是学员学习体验的直观感触,间接影响续费率和转介绍率。 作为实时互动底层 PaaS 厂商,咱们针对美术教学畛域提供了业余的解决方案,让企业专一于业务,让老师和学生专一于教学,舒服地实现每一次发明美的课程。 04 为美术教学场景定制能力, ...

June 3, 2021 · 1 min · jiezi

关于音视频:拍乐云受邀QCon大会-详解音视频技术架构实践首发美术教学音视频方案

5月29日上午,在「QCon 北京寰球软件开发者大会」上,拍乐云Pano 创始人赵加雨受邀作为「音视频服务解决方案专场」的首位技术专家,为大家带来实时音视频技术架构的深入分析,并解说拍乐云在视频通话、互动白板和弱网反抗技术中的最佳实际,同时,正式公布业内首个「美术教学实时音视频计划」,引发泛滥关注和好评。 QCon 是由极客邦科技旗下 InfoQ 主办的综合性技术盛会,面向5年以上工作教训的技术负责人、架构师、工程总监、开发人员分享技术创新和最佳实际。除了北京,每年还会在伦敦、东京、纽约、圣保罗、上海、旧金山等地召开。 实时音视频产品在线上化、数字化的趋势下,已成为各行各业的刚需。拍乐云Pano团队作为新一代实时音视频云服务领军者,在RTC技术方面有近20年的深厚积攒,并重视摸索这些翻新技术在业务场景中的价值与落地,以下为演讲实录。 1实时音视频的“两高一低” 实时音视频十分强调“两高一低”,即高质量、高晦涩和低时延。 高质量是指音频高保真,无回声噪声,音量适中,视频清晰; 高晦涩是指音视频晦涩无卡顿; 低时延在实时音视频产品里是十分重要的指标。ITU-T倡议规范里提到,如果端到端时延低于200毫秒,用户体验会十分好,时延在200~400毫秒时用户体验降落但能够承受,时延超过400毫秒的话少数用户都会不称心。 为了实现实时音视频的两高一低,须要在零碎架构、音视频编解码、寰球组网、服务端散发、弱网反抗等各个环节做到最优。一般而言咱们应该尽量兼顾“两高一低”这三个指标,然而在理论场景中往往无奈做到兼顾,那么咱们就会在“两高一低”里有所取舍。在视频会议场景下个别是保障高晦涩低时延,可能会适当就义高质量;而在美女直播、电商直播等场景下,高质量低时延可能更重要一点,会适当就义视频流畅性,少数场景下低时延都是要尽量保障的。 2音视频技术总体架构 拍乐云的技术架构来源于视频会议架构,并在此基础上做了演进迭代。 一个典型的视频会议架构个别是多DC、分布式的,客户端就近接入,媒体服务器可能会进行同DC和跨DC级联。视频会议架构非常复杂,外面波及的技术点有很多,包含:客户端如何实现就近接入、如何进行寰球组网和智能路由、音视频编解码怎么抉择和优化、服务端应用SFU还是MCU、端到端的QoS怎么实现、与PSTN网络和传统的SIP终端如何实现互联互通、级联怎么做等等。 从另一个维度讲,拍乐云技术架构也是十分典型的微服务架构,有配置核心、服务注册与发现、全局调度、认证受权等服务治理模块,也无限流熔断、弹性伸缩容、监控报警、大数据平台、Pano Backbone等保障服务高可用的组件,提供的外围性能有音视频通话、互动白板、互动直播等。 3互动白板技术实际 互动白板是在线教育、企业培训等场景下的刚需性能,一个好的互动白板产品须要解决这几个问题: 性能,时延是不是足够低?频繁互动时笔迹同步是否实时?在弱网时是否会同步不及时或者呈现白屏?咱们采纳了公有数据格式并做了极致压缩,确保数据量尽量小,在白板绘制和渲染时采纳原生技术,确保内存占用更低、CPU耗费更小,在网络传输上利用咱们的寰球减速网络 Pano Backbone 确保了跨国、跨运营商的实时传输。 动效课件反对得如何?课件里的音频和视频播放是否反对?咱们自研了转码引擎和白板引擎,能够做到动静课件的超高保真,也能够反对各种动效和音视频文件播放。 和音视频的同步推流和同步录制怎么实现?咱们同时提供音视频和白板性能,因而只须要一次API调用就能够实现音视频和白板的同步录制和推流,用户应用起来会十分不便。 4弱网反抗技术实际 互联网有几个特点,首先互联网实质上是尽力交付,而不是牢靠交付。当呈现拥塞和弱网时,可能就会有丢包等。其次互联网比拟强调公平性,一者互联网对于所有数据包是同等对待的,当呈现拥塞时可能会无差别的丢包,二者咱们在做弱网反抗时也须要思考公平性,不要把拥塞控制算法设计的特地激进,最初,互联网有各种跨国、跨洲、跨运营商的问题。常见的网络问题有:带宽受限、抖动、时延、丢包、乱序等。 抵制弱网须要软硬两手抓,硬件次要是指基建和调度算法,软件是指各种QoS算法。 在网络基建层拍乐云构建了寰球实时传输减速网络Pano Backbone,能够实现寰球减速、智能路由和用户就近接入。 在软件层,咱们的QoS算法包含几局部,首先是带宽评估和拥塞判断,个别是基于丢包、时延、RTT等指标来判断拥塞。在感知到拥塞又能够做各种抗丢包的策略,包含FEC、ARQ、RED等,这些策略算法各有优缺点。最初网络QoS并不仅仅是抗丢包,还包含平滑发送、慢启动、关键帧申请等各种拥塞管制伎俩。 咱们做任何的弱网反抗都不要遗记“两高一低”,每一种QoS算法都有实用的场景,如果用错了场景,可能会带来比较严重的副作用,譬如ARQ算法,当呈现70%丢包时,如果咱们心愿实现99.9%的包达到率,那么就须要重传20次,即便RTT只有100毫秒,最终传输数据包也须要2秒,这个时延在实时零碎里是无奈承受的。再比方FEC,当呈现70%丢包时,为了达到99.9%的包复原率,以5个原始包为例,也会导致790%的冗余率,这个对于带宽耗费是十分高的。咱们须要在呈现弱网时,依据不同场景抉择不同的抗弱网算法,最终依然要保障高质量、高晦涩和低时延。 5独创美术教学音视频计划 在线教育是实时音视频很重要的一个利用场景,联合咱们的技术积攒和客户的须要,咱们推出了美术教学音视频解决方案,帮忙客户构建一个强互动、沉迷式的美术教学线上课堂。通过多摄像头能力能够实现老师、学生双向同时看到对方的视频和画板;通过角度改正能够将画板调整为正对拍摄的成果;通过视频标注能力能够随时指出绘画时的重点和要点;通过动效课件能够十分不便地进行绘画教学;通过云端录制不便地进行课后回放和温习;通过 Pano Backbone 实现寰球用户的就近接入。 对于拍乐云 拍乐云成立于2019年,由红杉中国种子基金领投,是国内惟一一家视频会议背景的实时互动通信云服务商。公司汇聚了一大批专一于音频、视频、白板、网络、AI等畛域的资深技术专家。通过集成 Pano SDK,企业开发者即可在寰球范畴内疾速实现互动小班、超级小班、双师大班、语音聊天室、视频社交、直播连麦、游戏语音、视频客服、近程医疗、办公合作等场景。

June 3, 2021 · 1 min · jiezi

关于音视频:2021-全球技术领导力峰会-融云布道技术领导力进阶之路

5月21日-22日,由TGO鲲鹏会、极客邦科技主办的“2021 GTLC 寰球技术领导力峰会”寰球总站在上海召开。本届峰会邀请了数十位行业技术首领,以“构建技术领导力,成为引人追寻的管理者 ”为主题,开展了深度交换与思维碰撞。 其中,寰球当先的互联网通信云厂商融云作为To B畛域的技术守业代表受邀参会。会上,融云联结创始人&CTO、TGO 鲲鹏会(北京)负责人杨攀发表了《经营 To B 企业,如何寻求产品、商业与技术的均衡》的主题演讲,分享了守业实际中,如何抉择和确定守业赛道,产品、商业、技术的关系,以及如何不偏离企业战略目标等内容,帮忙技术管理者向领导者进阶,从而吸引更多的追随者,组建更有战斗力的团队。 TO B市场技术守业的机会 融云创建于2014年,始终专一于To B畛域的互联网通信云赛道,以“IM+RTC+PUSH”整体通信解决方案赋能千行百业。之所以抉择To B畛域进行技术守业,这与融云外围开创团队全副来自于原中国移动的飞信团队有很大关系。彼时,杨攀率领团队以技术撑持着日活过亿的飞信产品,他们看到了To B市场呈现了新的守业机会,以SDK/API形式交付开发者底层通信能力,凭借多年C端市场的技术积攒与经营教训,让杨攀团队抉择了To B赛道,为更宽泛的开发者提供PaaS平台级的通信能力。 自那一年后,市场上每年都在讲To B市场的元年来了。但杨攀认为,2021年才是To B市场真正的开启之年。起因有四个:流量、人才、资本与疫情。 第一,从流量看,To C 流量进一步向超大 App 汇集,开发者除了开发成本外,经营老本逐年攀升。 第二,从人才流动看,To C 产业人才、硅谷人才、中国外企人才,这三个方面的人才逐年向To B 市场溢出。 第三,从资本看。To C 业务倒退遭逢瓶颈,流量被大厂管制,机会不多,因而To C 资本逐步溢出,去向更有钱赚的中央,那就是To B市场。 第四,从疫情看。疫情减速了国内信息化建设,由原先较为平缓的建设,倒退为跳跃性的建设,让本来对信息化无概念的公司管理者意识到信息化的重要性。 基于上述四个方面的起因,杨攀认为抉择To B畛域技术守业正过后。 寻求产品、商业与技术的均衡 抉择和确定守业赛道,依附的是团队之前的技术积攒和经营教训;但经营一家To B企业,则面临如何均衡产品、商业与技术这三者关系的课题。 杨攀认为,产品负责“做什么成”,通过市场钻研、竞争剖析、客户钻研、商业策动、产品定义、经营数据分析等决定守业公司的产品方向;技术负责“做成什么”,也就是公司外围能力的构建,包含品质劣势、老本劣势、开发者效率劣势等方面;商业负责“怎么做成”,这就须要剖析营收增长、客户增长模型,由市场创立销售漏斗,售前和销售独特达成工作。 一个公司,是销售部门强势?是产品部门强势?还是技术部门强势?取决于如何帮忙客户胜利,同时又不偏离公司既定的策略方向。当技术管理者面对市场的变动,竞争对手的追赶,仍旧可能理清这两者的关系,寻求产品、商业与技术的均衡时,就是一个优良的技术管理者向领导者进阶的过程。 因为守业公司高层的视角永远是看方向,看似讲均衡,其实是协调一致,施展团队现有人员的最大效劳。 真正平凡的企业有所为,有所不为 如何看准方向,不偏离公司既定的战略目标?杨攀给出的答案是:真正平凡的企业有所为,有所不为。这就是策略的实质:取舍与排序。 每一个领导者都应考虑,公司战略目标应该是客户驱动?对手驱动?还是策略驱动?怎么取舍?怎么排序? 客户驱动最大的问题在于:满足了客户需要,往往可能偏离了公司既定的策略方向;最大的益处是通过满足个性化的客户需要,可能会发现一个潜在的商业畛域,把它做成普适性的产品,进而成为公司策略方向的一部分。因而当一个公司深陷客户驱动的时刻,就要认真扫视其最大的弊病和益处,进行取舍。 对手驱动,领导者应该要求不能纯正的 “抄作业”,而是要以对手为镜,学习战术打法,造成策略层面的独立思考。一味模拟,只会因彼此门路不同、资源不同、内核逻辑不通,反被入坑。 策略驱动,在杨攀看来,是所有管理者都应该做的事件,但往往短期内不会获得成功反馈。一个To B畛域的守业公司应该谋求长期价值主义,好高鹜远打磨技术与场景,谋求为开发者带来超值体验与服务。 因而,一家真正平凡的企业,应该要顶住压力做该做的事件,兴许艰巨,但会一路向上;摒弃短效利益,确保外围指标的达成。 结语 技术管理者应该铭刻心中:商业的实质是增长与效率,策略的实质是取舍和排序。杨攀通过融云的守业实战,分享了技术管理者向领导者进阶过程中,应如何保持既定策略方向,均衡产品、商业与技术,让公司与领导者疾速成长,向做一家平凡的企业后退。

May 28, 2021 · 1 min · jiezi

关于音视频:2021年中国信创生态报告发布-指引未来信创产业发展

“中国市场的数字化过程进入数智化时代后,企业对数智产品的独特需要推动信创倒退。”这是日前公布的《2021中国信创生态市场钻研报告》(以下简称《报告》)中,对于信创倒退的背景解读。而从软件和信息产业对经济的奉献来看,曾经从 2010年 的3.2% 进步到了 2020 年 8%,信创产业正成为推动经济倒退的重要力量。 融云作为信创产业链企业应用环节的代表,被列为示范厂商 信创生态产业链涵盖上游、中游和上游共六大环节,上游包含以龙芯、华为为代表的底层硬件和基础设施;中游包含以达梦、用友为代表的根底软件和平台服务;上游包含以融云、致远互联为代表的企业应用和解决方案。《报告》认为:产业链上游倒退较为成熟,作为企业应用环节的代表之一,融云是信创产业的示范厂商。 图1:信创生态产业链 融云成为信创生态产业图谱中“应用软件”和“利用场景”两大版块的举荐厂商 从市场总体判断来看,根底软件环节被认为是信创生态体系中的要害策略环节,其次是企业应用和平安环节。因而,像麒麟软件、达梦数据库这类的根底软件厂商,用友、融云等应用软件厂商在信创畛域能施展重要作用。又因融云可联合行业场景,提供金融、公检法、教育、能源等行业整体通信解决方案,因而,融云同时成为信创生态产业图谱中“应用软件”和“利用场景”两大版块的举荐厂商。 图2:信创生态产业图谱 融云处于企业应用软件营垒,入选厂商自主信创产品的第一梯队 在信创供应侧剖析中,《报告》特地指出:企服软件、安全软件、数据库、解决方案等产品在自主知识产权方面比例较高。从厂商自主信创产品种类来看,企业应用软件、安全软件、数据库、解决方案、平安硬件为第一梯队,像融云等专一企业应用软件的厂商会有更好的倒退空间。 图3:厂商自主信创产品种类 融云作为企业通信领导品牌的劣势剖析:100%自主知识产权、成熟商业模式、数千家政企客户 《报告》明确将平安可信的通信云厂商融云定位为“企业通信领导品牌”,成为“信创厂商竞争格局”中典型厂商,并对其进行了劣势剖析。 第一,融云领有技术上的自主知识产权。信创厂商的均匀自主知识产权覆盖率为29%,阐明厂商在自主知识产权方面仍有较大晋升空间。而融云则领有100%的自主知识产权,无论是寰球通信网络的底层架构搭建,还是IM和RTC的产品迭代开发,融云从写第一行代码起,就对其领有全副的知识产权。因而,报告认为像融云这样在技术自主知识产权方面具备劣势的企业,会成为信创畛域的明星企业。 第二,融云领有成熟的商业模式。融云在政企行业抉择与SI/ISV单干,就繁多行业而言,由融云向 SI/ISV 合作伙伴提供标准化的通信解决方案,对于客户定制化的需要,则由 SI/ISV 进行个性化开发及我的项目交付,单方独特为党政、国企和金融、教育、医疗等行业的最终用户赋能。这种商业模式,被报告作为三个典型的商业模式之一加以推介。 图4:融云To B政企市场的商业模式 第三,融云领有数千家政企客户胜利案例。时至今日,融云已服务包含中国石油、中国工商银行、招商银行、中国农业银行、交通银行、四川航空、铁科院、华泰证券、国泰君安、陆金所、联想、科大讯飞、中联重科、金鹏电子、中科软、中国移动等上千家政企客户。《报告》中同时被列为示范企业代表的致远互联、用友、泛微知名企业等也都是融云客户。 图5:融云To B政企市场的商业模式 融云作为将来热点厂商的举荐剖析:全面反对国产化、提供平安可信的企业通信解决方案 《报告》剖析了用户对信创生态的需要偏好,除了国产化适配反对外,安全类信创产品需要最高。 在国产化适配反对方面,目前融云全面适配支流国产化软硬件,反对河汉麒麟、统信 UOS、达梦、人大金仓、神州通用等多家国产操作系统及国产数据库、操作系统、数据库、中间件等组件的200多种组合。并且,实现了与普元、达梦、致远、金蝶等多家支流国产化厂商的产品互认。 作为平安可信的通信云服务厂商,融云可为政企客户提供多重平安部署与防护,提供全行业的通信解决方案。首先,对于窃密级别要求更高的党政、国企客户,融云反对私有化部署,可将服务部署在指定服务器,反对专网外部部署,满足数据窃密需要;其次,融云领有自主可控的加密链路,并具备可验证性。信息数据传输前后,通过对数据包抓取剖析,能够验证加密前后的成果,破解难度极大,破解工夫老本极高,从而帮忙政企行业用户疾速构建信创环境下安全可靠的通信能力。 鉴于此,融云成为《报告》所举荐的将来热点厂商,以及应用软件的示范厂商。 图6:融云入选将来热点厂商案例举荐目录 结语 通过对2021年中国信创生态报告的解读,咱们理解到信创市场是”技术+政策“的双驱动型市场,不仅受政策影响,技术先进性、成熟度、自主可控更重要。信创畛域会重塑中国市场“重利用、轻技术“的传统格局,促使市场转型进入技术驱动型市场。因而,像融云这类技术自主可控、全面反对国产化适配,且有成熟解决方案和最佳实际的厂商,将来在信创市场上将庸庸碌碌。

May 24, 2021 · 1 min · jiezi

关于音视频:融云-2021-XMeetup-技术沙龙-探讨音视频技术新方向

2021 年 5 月 15 日,融云 X-Meetup 技术沙龙第三站续航上海。本场沙龙聚焦“音视频技术新方向”,由融云音视频研发高级工程师姜春雨、时光机器人创始人兼 CEO 徐晶、融云 IM 研发核心高级工程师刘佳、学而思网校架构师李亚龙,和资深音视频技术专家栗伟,五位技术大咖出任演讲嘉宾,他们以时下热门利用场景为视角,从技术实际登程,与开发者们交换分享了对于音视频技术的新察看。 iOS 上的音频开发 往年,因为 Clubhouse 和 Tiya 的示范效应,语聊房产品大火,音频的开发技术备受开发者的关注。来自融云的音视频研发高级工程师姜春雨,多年专一于挪动端和音视频畛域的技术研发,他分享了《iOS 音频设备开发 - Core Audio》的主题内容。 融云音视频研发高级工程师姜春雨发表演讲 姜春雨认为:挪动端音频解决的难点在于声音丑化、变声、实时高音质和场景玩法多样化。单从 iOS 设施来说,要冲破这些难点,离不开 iOS 所提供的 Audio Unit,它是一项弱小灵便的音频解决技术,反对混合、平衡、格局转换和实时输出/输入,用于录制、播放、离线渲染和实时对话。 融云 SDK 以 Audio Unit 为根底,构建了长音效、短音效等多个功能模块,最终在音频设备上实现混音输入。在场景化实际中,姜春雨以音乐语聊房和百人超大会议室两个典型场景为例,分享了融云 SDK 的技术开发优化计划。比方,音乐语聊房重视高音质、美声变声,以舒服乐音为好,开发者要依据这些需要进行算法调优;而超大会议室的优化则要求做到服务端智能发流、多人声音同时呈现能够智能抉择会议发言人的声音。 姜春雨总结道:Audio Unit 是一个弱小的音频解决框架,音频解决要基于 Audio Unit 框架构建内容,并且要在音频解决内容上一直打磨优化。将来,融云音视频 SDK 还将一直基于不同场景须要开发新的性能,继续优化音频产品,为开发者提供更好的解决方案。 构建低提早高牢靠的信令零碎 融云作为互联网通信云赛道的当先厂商, 2020 年在业界率先提出“IM+RTC+PUSH”的整体通信解决方案。融云 RTC 唤起用户的通道就是依赖于 IM 的 SDK 信令,因而,本次融云的 IM 研发核心高级工程师刘佳,分享了《构建低提早高牢靠信令零碎的摸索与实际》,帮忙开发者更好地理解融云 IM 如何协同 RTC,提供高牢靠的通信能力。 融云 IM 研发核心高级工程师刘佳 刘佳介绍,高牢靠音视频信令零碎的构建在 IM 信令零碎设计时,首先要进行服务分层,包含接入层、外部服务和数据存储的分层。而拆分准则要依据业务差别和服务对象的不同,拆分为 API 和 CMP,整体做到可监控、可保护。其次,是要搭建残缺的监控体系,通过可视化的图表,监看网络的性能状况,及时处理零碎瓶颈。 ...

May 21, 2021 · 1 min · jiezi

关于音视频:FFMPEG解封装函数介绍

1. 简介应用FFmpeg对音视频流进行解封装是解决音视频输出的初始步骤,FFmpeg提供了丰盛的接口函数进行该操作,上面对一些重要函数性能进行具体介绍。 2. 根本函数介绍1. av_register_all()函数原型: void av_register_all(void);函数性能:初始化所有组件,在函数外部会对编解码器和复用器进行注册。 2. avformat_network_init()函数原型: int avformat_network_init(void);函数性能:加载socket库以及网络加密协议相干的库,为后续应用网络相干性能提供反对 3. avformat_open_input()函数原型: int avformat_open_input(AVFormatContext **ps, const char *filename, AVInputFormat *fmt, AVDictionary **options)函数性能:用于关上多媒体数据并且获取相干信息参数阐明:AVFormatContext **ps:函数如果调用胜利,会将获取到的音视频信息存入AVFormatContext构造体ps中。const char *filename:关上的音视频流的URL。AVInputFormat *fmt:能够强制指定AVFormatContext中的AVInputFormat。该参数个别状况都设置为NULL,示意FFmpeg能够自动检测AVInputFormat。AVDictionary **options:附件的一些选项,个别也设置为NULL。返回值:调用胜利返回值>=0 4. avformat_find_stream_info()函数原型: int avformat_find_stream_info(AVFormatContext *ic, AVDictionary **options);函数性能:读取一部分音视频数据并由此取得一些该视频的相干信息。参数阐明:AVFormatContext *ic:将获取到的流信息存入ic中供后续应用。AVDictionary **options:额定的选项,个别设置为0。返回值:调用胜利返回值>=0 5. av_find_best_stream()函数原型: int av_find_best_stream(AVFormatContext *ic, enum AVMediaType type, int wanted_stream_nb, int related_stream,                        AVCodec **decoder_ret, int flags)函数性能:用于获取音频流、视频流索引。参数阐明:AVFormatContext* ic:获取到的AVFormatContext。enum AVMediaType type:输出对应要寻找的具体类型流信息(音频、视频)。int wanted_stream_nb:个别设置为-1。related_stream:个别设置为-1。AVCodec** decoder_ret:个别设置为NULL。int flags:个别设置为0。返回值:调用胜利返回值>=0 6. av_read_frame()函数原型: int av_read_frame(AVFormatContext *s, AVPacket *pkt);函数性能:用于获取一帧残缺的图像数据,或者取得多帧残缺的音频数据。参数阐明:AVFormatContext *s:获取到的形态格局上下文AVFormatContext。AVPacket *pkt:这个值不能为NULL,必须是一个开拓好的空间,用于接管AVPacket数据返回值:调用胜利返回值>=0 7. av_seek_frame()函数原型: int av_seek_frame(AVFormatContext *s, int stream_index, int64_t timestamp, int flags);函数性能:用于寻找某个特定帧。参数阐明:AVFormatContext *s:获取到的形态格局上下文AVFormatContext。int stream_index:根本流索引,示意seek是针对哪一类流数据(音频或视频)。int64_t timestamp:要seek的工夫点,以time_base为单位。int flags:标记位,用于设置seek的形式。返回值:调用胜利返回值>=0 ...

May 17, 2021 · 1 min · jiezi

关于音视频:融云亮相-CDEC2021-上海站-全场景通信能力赋能企业数字升级

4 月 22 日,由海比研究院、中国软件行业协会等反对,中国软件网主办的 CDEC2021 中国数字智能生态大会暨第十四届中国软件渠道大会上海站流动,隆重召开。 CDEC2021中国数字智能生态大会上海站 融云与上海本地数百家ISV、SI、渠道商、服务商一起缺席流动,独特探讨数智时代企业倒退的新机遇、新思路,以及融云如何深耕信创产业,更好地携手 SI/ISV 合作伙伴,独特为政府、金融、教育等行业客户赋能通信云能力。会上,融云联结创始人& CEO 韩迎发表了《互联网通信技术新趋势 融云赋能企业数字降级》的主题演讲。 融云全面满足数智时代的企业通信需要 演讲中,韩迎首先介绍了融云创建以来的倒退历程。融云创建 7 年,开创团队核心成员来自中国移动的飞信团队,始终以来专一于通信云赛道,通过与 SI/ISV 的单干,为政企行业客户提供“IM+RTC+PUSH”的整合通信能力。 据艾瑞报告显示,融云间断多年在 IM 畛域市场占有率第一,实时音视频位居第一营垒;在技术层面,融云是行业内首家在互联网市场、政企行业市场两大市场均能够提供整体通信解决方案的服务商,能够为客户提供“全”场景的通信服务。 尤其是政企行业市场,融云从 2017 年开始,携手 SI/ISV 合作伙伴,服务了包含中国工商银行、中国移动、联想、科大讯飞、致远等数千家知名企业。后疫情时代,因为客户在线协同办公、在线会议、在线视频等的应用习惯被养成,以及国家信创产业的策略须要,融云将继续深耕政企市场,为企业数字降级赋能底层的通信能力。 融云联结创始人 & CEO 韩迎发表演讲 融云赋能多行业翻新的利用场景 去年开始,融云依据政企行业市场不同场景的通信须要,构建了通信中台和行业解决方案。“通信中台”最大的价值是将融云的产品从“中间件”状态转变为标准化的解决方案,融云 CEO 韩迎强调,“原来融云所做的其实是很浅的 SDK 通信层,不波及客户的业务,客户须要调用SDK来实现在线聊天、在线音频、在线视频的能力;当初融云把利用上的一些反复的共性需要形象进去,将通信模块和功能模块打包组合成通信中台;这样能够节俭客户的工夫,融云多做了一点,客户就能够少做一点。” 这样,融云的通信中台和行业解决方案就满足了 SI/ISV 合作伙伴在开发集成中的低成本、高效便捷的需要。由融云赋能的通信能力,通过与SI/ISV合作伙伴的单干,已广泛应用于政务、公检法、金融等政企行业个性化翻新场景。例如: 场景一:智慧警务。融云 IM 和实时音视频产品与 GIS 地理信息服务联合,在地图上嵌入低代码通信中台能力当前,以点为核心,半径一公里内的警务人员可实现疾速建群、疾速指挥调度。通过与合作伙伴金鹏公司单干,融云公检法解决方案可全面晋升公安机关应答重大警情、重要流动等突发公共事件的疾速响应和应答能力。 场景二:近程合作。由融云和中国移动单干打造的中国移动近程割接零碎,使中国移动有了遍布全国的近程合作平台。远在北京的5G专家,可通过近程合作平台,在近程多人合作场景中,领导上海的现场操作。 场景三:近程司法。融云通过与合作伙伴的深度单干,为司法部门打造了近程庭审零碎,除了可实现近程庭审,还可实现科技法庭,近程探监,执法近程指挥等多重通信能力。 场景四:智慧城市。融云 IM 与音视频服务助力政府实现“G To B”、“G To C”通信桥梁的建设,将便民、便企等业务统筹规划,一体建设,在政府与企业和市民之间构建高效便捷的通信网络。 场景五:金融社交。由融云赋能的工商银行融e联,实现分级、分层、分区域音讯的上传下达,包含不同层级的客户经理之间的沟通。融云底层通信能力可助力银行实现互联网金融策略,倒退成信息丰盛、交互即时、安全可靠的社交型金融服务平台。 此外,协同办公、近程医疗、远程教育等诸多场景中,融云的隐形能力无处不在。韩迎总结道,“融云在企行业通信中台的利用场景和模块,都是咱们和不同客户独特打造进去的。融云十分违心和每一个行业外面的客户,独特打造不同的通信中台场景。” 融云积极支持信创产业 政企行业市场,是融云这两年继续发力的次要市场之一。要想深耕政企市场,积极支持信创产业是融云的一贯策略。韩迎在演讲中特地提到,“这两年都在提‘信创、国产化’,将来3-5年可能都是中国企业级市场的机会,特地是对大客户、国企、央企、政府客户而言,信创是一个十分重要的国产化代替过程。” 因而,为了响应国家信创策略要求,满足政府机关和央企、国企的国产化利用需要,2019 年开始,融云针对政企行业上云发展国产化适配反对,将通信云能力迁徙到国产化的各个平台上。通过继续两年的研发投入,目前,融云曾经全面反对国产化芯片、操作系统、中间件及数据库组件的百余种组合,并与这些国产化软硬件厂商实现了零碎互认。 并且,融云已正式退出信息技术利用翻新工作委员会,成为 PaaS 云通信畛域率先入会的会员。这表明融云踊跃拥抱国产化过程的初心未改,将来,将会发展平安办公通信畛域的规范及白皮书的制订工作。 融云展台 会场外,在融云展台,通过产品展现和介绍,与会者也能够理解到融云正以更牢靠、更便捷、更高质量的通信产品和服务,为政企行业客户及互联网开发者的翻新场景利用,赋予底层通信能力。 结语 应该说,融云倒退到明天,不仅提供私有云的服务,公有云的服务也十分成熟,特地是信创畛域的公有云部署。因政企客户的行业属性和应用场景不同,对于国产软硬件产品也有着不同的抉择,融云认为,通信云能力作为 PaaS 层的两头技术,须要笼罩全行业和全场景的应用需要,这就要求云厂商可能在技术与场景上全面兼顾客户的须要,以即时通讯和实时音视频产品为外围,构建通信中台和行业场景解决方案,赋能企业数字降级。 ...

May 6, 2021 · 1 min · jiezi

关于音视频:音视频基础概念

声波三要素:频率、振幅和波形。频率代表音阶的高下,振幅代表响度,波形代表音色。 采样、量化和编码 奈奎斯特定理(采样定理):按比声音最高频率高2倍以上的频率对声音进行采样(也称为AD转换)。人耳能听到的频率范畴是20Hz~20kHz,所以采样频率个别为44.1kHz(1秒采样44100次)。 通常所说的音频的祼数据格式就是脉冲编码调制(Pulse Code Modulation, PCM)数据。形容 PCM 需用到的概念:量化格局(sampleFormat)、采样率(sampleRate)、声道数(channel)。 比特率(以 CD 音质为例,量化格局或称位深度为16比特、采样率为44100,声道数为2),CD的数据比特率 44100 16 2 = 1378.125kbps 1分钟内所占的存储空间: 1378.125 * 60 / 8 / 1024 = 10.09MB 分贝 N= 10 * lg(A1 / A0) 其中A0是基准量(或参考量), A1是被量度量 压缩编码的根本指标之一就是压缩比,压缩算法包含有损压缩和无损压缩。压缩编码算法,如PCM、WAV(多媒体开发的两头文件、保留音乐和音效素材)、AAC(128Kbit/s以下的音频编码,多用于视频中音频轨的编码)、MP3(高比特率下对兼容性有要求的音乐欣赏)、Ogg(比MP3更小的码率实现比MP3更好的音质,实用语音聊天的音频音讯场景)等。压缩编码的原理是压缩掉冗余信号(耳听觉范围之外的音频信号以及被掩蔽掉的音频信号等),掩蔽掉的音频信号则次要是因为人耳的掩蔽效应,次要体现为频域掩蔽效应与时域掩蔽效应。 三原色光:红光(R)、绿光(G)、蓝光(B)。子像素示意形式 浮点示意:取值范畴为0.0~1.0,比方,在OpenGL ES中对每一个子像素点的示意应用的就是这种表达方式。整数示意:取值范畴为0~255或者00~FF,8个比特示意一个子像素,32个比特示意一个像素,这就是相似于某些平台上示意图像格式的RGBA_8888数据格式。比方,Android平台上RGB_565的示意办法为16比特模式示意一个像素,R用5个比特来示意,G用6个比特来示意,B用5个比特来示意。1280×720的RGBA_8888图像的大小:1280 * 720 * 4 / 1024 / 1024 = 3.516MB YUV数据格式,其中“Y”示意亮堂度(Luminance或Luma),也称灰阶值;而“U”和“V”示意的则是色度(Chrominance或Chroma)。Y的取值范畴都是16~235, UV的取值范畴都是16~240。YUV最罕用的采样格局是4:2:0,即如果某一行是4:2:0(4Y-2U-0V),那么其下一行就是4:0:2(4Y-0U-2V)...对非压缩的8比特量化的视频来说,8×4的一张图片须要占用48字节的内存: 1280×720的视频帧,用YUV420P的格局来示意,数据量的大小: (1280 * 720 * 1 + 1280 * 720 * 0.5) / 1024 / 1024 = 1.318MB ...

April 28, 2021 · 1 min · jiezi

关于音视频:多场景实时音视频通信激增背后RTC-技术大爆发

音视频社交软件 Clubhouse 的估值较 3 个月前又翻了两番。当地工夫 4 月 19 日,Clubhouse 发表实现 C 轮融资,估值已达 40 亿美元。 而这只是实时音视频通信大暴发中的冰山一角。 在马斯克“直播带货”的催化下,越来越多的语聊房产品呈现,Facebook 也被爆出行将推出 Clubhouse 同类竞品。不仅如此,在线办公、在线教育、泛娱乐场景中对实时音视频的需要也在激增。 得益于 5G、RTC 等技术的倒退,一间语聊房、或是流动直播间、在线课堂等都能够疾速实现搭建并公布,进一步刺激实时音视频市场。以融云实时音视频服务为例,开发者只需三步,就能够在 30 分钟内疾速集成音视频能力: 第一步,申请开发者注册,官网会发送 App key 等信息,下载 SDK。这一步骤通常十分钟内能够实现。 将下载好的 SDK 集成到本人的开发工具里,初始化 SDK,而后退出房间。初始化 SDK 可帮忙初始化设施、音视频相干参数等。 公布本人的音视频流和订阅他人的音视频流。 5G 时代须要更便捷的 RTC 技术服务 为何市场须要疾速集成实时音视频的能力? 一方面,在 5G 的作用下,许多传统互联网场景中正在嵌入实时音视频性能。另一方面,专一利用层面的厂商须要以最小的老本,最快的速度上线性能,以撑持产品的公布和经营。 融云 CTO 任杰认为,5G 给 RTC 市场带来两大方面的变动。 一是 5G 的宽带和延时有较大晋升,所以将来高清的、低提早的音视频通话将会成为支流。在 4G 网络之下,实时音视频通话支流的为 720p,1080p 稳定性略有有余。而在 5G降临之后 ,1080p 甚至是更高清的 4K、8K 通话场景会广泛减少。 二是减少各种物联网设施接入。此前 RTC 实时音视频畛域中,次要是挪动端、PC 端利用。其余物联网设施如车机、摄像头、大屏设施等接入较少。任杰认为,在 5G 到来之后,各种物联网设施的接入场景也会减少。从技术层面看,5G 解决提早问题之后,大量设施都可接入,许多实时操作系统 ATOS ,以及 Linux 在 RTC 畛域的利用场景也会变得更加支流。 ...

April 26, 2021 · 1 min · jiezi

关于音视频:一篇文章带你简单了解音频视频

一、概述1)流媒体协定是服务器与客户端之间通信遵循的规定。以后网络上次要的流媒体协定如表所示。 2)封装格局的次要作用是把视频码流和音频码流依照肯定的格局存储在一个文件中。 3)视频编码的次要作用是将视频像素数据(RGB,YUV等)压缩成为视频码流,从而升高视频的数据量。如果视频不通过压缩编码的话,体积通常是十分大的,一部电影可能就要上百G的空间。视频编码是视音频技术中最重要的技术之一。视频码流的数据量占了视音频总数据量的绝大部分。高效率的视频编码在等同的码率下,能够取得更高的视频品质。 4)音频编码的次要作用是将音频采样数据(PCM等)压缩成为音频码流,从而升高音频的数据量。音频编码也是互联网视音频技术中一个重要的技术。然而个别状况下音频的数据量要远小于视频的数据量,因此即便应用略微落后的音频编码标准,而导致音频数据量有所增加,也不会对视音频的总数据量产生太大的影响。高效率的音频编码在等同的码率下,能够取得更高的音质。 二、流媒体协定 三、封装格局 除了AVI之外,其余封装格局都反对流媒体,即能够“边下边播”。有些格局更“万能”一些,反对的视音频编码标准多一些,比方MKV。而有些格局则反对的绝对比拟少,比如说RMVB。 四、视频格式 不同编码规定的比照 熵编码:如果要求编码过程中不失落信息量,即要求保留信息熵(对信息量多少的度量),这种信息放弃编码叫熵编码,是依据音讯呈现概率的散布个性而进行的,是无损数据压缩编码。 I帧 P帧 B帧1)I帧示意关键帧,你能够了解为这一帧画面的残缺保留;解码时只须要本帧数据就能够实现(因为蕴含残缺画面) 2)P帧示意的是这一帧跟之前的一个关键帧(或P帧)的差异,解码时须要用之前缓存的画面叠加上本帧定义的差异,生成最终画面。(也就是差异帧,P帧没有残缺画面数据,只有与前一帧的画面差异的数据) 3)B帧是双向差异帧,也就是B帧记录的是本帧与前后帧的差异(具体比较复杂),换言之,要解码B帧,不仅要获得之前的缓存画面,还要解码之后的画面,通过前后画面的与本帧数据的叠加获得最终的画面。B帧压缩率高,然而解码时CPU会比拟累。 去块滤波:因为重构块的边缘像素与块外部像素相比复原精度要低,块效应是目前压缩编码最显著的视觉失真之一(图像相关性受到破坏)。 H.264 编码技术1)更高的编码效率:同H.263等规范的特率效率相比,可能均匀节俭大于50%的码率。 2)高质量的视频画面:H.264可能在低码率状况下提供高质量的视频图像,在较低带宽上提供高质量的图像传输是H.264的利用亮点。和MPEG2和 MPEG4 ASP等压缩技术相比,在等同图像品质下,采纳H.264技术压缩后的数据量只有MPEG2的1/8,MPEG4的1/3。显然,H.264压缩技术的采 用将大大节俭用户的下载工夫和数据流量免费。 3)进步网络适应能力:H.264能够工作在实时通信利用(如视频会议)低延时模式下,也能够工作在没有延时的视频存储或视频流服务器中。 4)采纳混合编码构造:同H.263雷同,H.264也应用采纳DCT(离散余弦变换)变换编码加DPCM的差分编码的混合编码构造,还减少了如多模式静止预计、帧内预测、多帧预测、基于内容的变长编码、4x4二维整数变换等新的编码方式,进步了编码效率。 5)H.264的编码选项较少:在H.263中编码时往往须要设置相当多选项,减少了编码的难度,而H.264做到了力求简洁的“回归根本”,升高了编码时复杂度。 6)H.264能够利用在不同场合:H.264能够依据不同的环境应用不同的传输和播放速率,并且提供了丰盛的错误处理工具,能够很好的管制或打消丢包和误码。 7)谬误复原性能:H.264提供了解决网络传输包失落的问题的工具,实用于在高误码率传输的无线网络中传输视频数据。 8)较高的复杂度:264性能的改良是以减少复杂性为代价而取得的。据估计,H.264编码的计算复杂度大概相当于H.263的3倍,解码复杂度大概相当于H.263的2倍。 H.265 编码技术1)H.265是新的编码协定,是H.264的升级版。H.265规范保留H.264原来的某些技术,同时对一些相干的技术加以改进。新技术应用先进的技术用以改善码流、编码品质、延时和算法复杂度之间的关系,达到最优化设置。 2)H.265相比H.264最次要的扭转是采纳了块的四叉树划分构造,采纳了从64x64~8x8像素的自适应块划分,并基于这种块划分构造采纳一系列自适应的预测和变换等编码技术。 3)H265能够实现利用1~2Mbps的传输速度传送720P一般高清音视频。同样的画质和同样的码率,H.265比H2.64 占用的存储空间要少实践50%。 4)H265提供了更多不同的工具来降低码率,以编码单位来说,H264中每个宏块大小都是固定的16x16像素,而H265的编码单位能够抉择从最小的8x8到最大的64x64。 较新的视频格式RM格局Networks公司所制订的音频视频压缩标准称之为Real Media,用户能够应用RealPlayer或RealOne Player对合乎RealMedia技术规范的网络音频/视频资源进行实况转播,并且RealMedia还能够依据不同的网络传输速率制订出不同的压缩比率,从而实现在低速率的网络上进行影像数据实时传送和播放。这种格局的另一个特点是用户应用RealPlayer或RealOne Player播放器能够在不下载音频/视频内容的条件下实现在线播放。 RMVB格局这是一种由RM视频格式降级延长出的新视频格式,它的先进之处在于RMVB视频格式突破了原先RM格局那种均匀压缩采样的形式,在保障均匀压缩比的根底上正当利用比特率资源,就是说静止和动作局面少的画面场景采纳较低的编码速率,这样能够留出更多的带宽空间,而这些带宽会在呈现疾速静止的画面场景时被利用。这样在保障了静止画面质量的前提下,大幅地进步了静止图像的画面质量,从而图像品质和文件大小之间就达到了奥妙的均衡。 五、音频格式 MP3(MPEG-1 audio layer 3)类型:Audio 制定者:MPEG 所需频宽:128~112kbps(压缩10~12倍) 个性:编码简单,用于互联网上的高质量声音的传输,如MP3音乐压缩10倍,2声道。MP3是在综合MUSICAM和ASPEC的长处的根底上提出的混合压缩技术,在过后的技术条件下,MP3的复杂度显得绝对较高,编码不利于实时,但因为MP3在低码率条件下高水准的声音品质,使得它成为软解压及网络播送的宠儿。长处:压缩比高,适宜用于互联网上的流传 毛病:MP3在128KBitrate及以下时,会呈现显著的高频失落 应用领域:voip 版税形式:Free 备注:同MPEG-1 audio layer 1 WMA(Windows Media Audio)类型:Audio 制定者:微软公司 所需频宽:320~112kbps(压缩10~12倍) 个性:当Bitrate小于128K时,WMA简直在同级别的所有有损编码格局中体现得最出色,但仿佛128k是WMA一个槛,当Bitrate再往上晋升时,不会有太多的音质扭转。 长处:当Bitrate小于128K时,WMA最为杰出且编码后失去的音频文件很小。 毛病:当Bitrate大于128K时,WMA音质损失过大。WMA规范不凋谢,由微软把握。 应用领域:voip 版税形式:按个收取 备注:WMA的全称是Windows Media Audio,它是微软公司推出的与MP3格局齐名的一种新的音频格式。因为WMA在压缩比和音质方面都超过了MP3,更是远胜于RA(Real Audio),即便在较低的采样频率下也能产生较好的音质,再加上WMA有微软的Windows Media Player做其弱小的后盾,所以一经推出就博得一片欢呼。 ...

April 19, 2021 · 1 min · jiezi

关于音视频:CTO-说要接入实时音视频-SDK我到底该批多少预算

过来一两年,在线教育迎来井喷式倒退,泛娱乐中的语音聊天、多人游戏、直播带货在去年也减速暴发,这些场景的背地离不开互联网技术的倒退与加持,这其中又尤以“实时音视频 RTC”为外围。寰球互联网通信云服务商“融云”示意:2020 年因为疫情的暴发,对 RTC 的需要甚至达到了数倍的增长。 在互联网企业中,当你的产品利用场景须要实时音视频通信,无论是思考工夫投入、人力收入还是技术研发、试错老本,齐全自研并不算理智的抉择。因而,当下大部分的开发者都会首选采纳成熟的第三方服务商的技术。 然而,对于大多数企业来说,如何能高效率的抉择最合适的 RTC 技术服务商本就是一件让人挠头的事。 服务过 30 多万款 APP 的融云认为,RTC 的好与坏,将间接影响这款利用的将来倒退。因而,RTC 技术是否能做到低延时、无卡顿、高清晰、无损音质是很重要的。除了这些能够评判的利用体验和质量标准之外,守业公司还较为关注云服务商的“定价”策略。 一些 RTC 服务厂商在定价层面不够敌对,尽管入门首次体验的门槛较低,但后续应用门槛比拟高,少则上千,多则上万,造成这一问题的要害还在于“无奈预计的应用时长下限”——个别服务商对于 RTC 的定价是基于总应用时长,即分钟数。一些新的 APP 我的项目上线之后,开发者接入 RTC,但个别无奈预期本人的产品一个月大略要耗费多少分钟数。对 RTC 的需要下限无奈把控,产品技术老本无奈预测,让很多开发者在抉择服务时难以抉择。 另外,一款利用开发实现后,上线经营的老本将占据初创企业较多资金,所以,开发者个别心愿后期 RTC 技术研发的投入越少、越可控,这样的云厂商对开发者较为敌对。 当初,融云针对守业企业推出了音视频产品特惠套餐,每个月只需 980 元的月性能费,开明后即可享 20 万分钟的收费时长,不限行业和应用场景,不限企业类型,不限视频分辨率,最高可反对 1080P。 每月 980 元对于初创企业和开发者来说,简直是零门槛的。而这 20 万分钟意味着什么? 据测算,在 4 人小班课场景下,按每堂课 45 分钟计算,20 万分钟能够实现 370 节,分辨率为 1080P 超高清晰度的在线课程;在近程会诊的场景下,依照每个人 30 分钟的会诊工夫,医生能够为 3333 个病人实现初诊;在语聊房场景下,6 个生疏小伙伴,每月能够畅聊 555 个小时……对于小规模或刚刚起步的初创企业而言,20 万分钟每个月是足够可用的。 当然,一家可长期单干的、优质的RTC服务商,除了在定价策略上体现对用户的敌对之外,其对行业场景的理解、技术品质、服务保障和团队底色等更为重要和根底。 以音视频通信 RTC 为外围的利用场景十分宽泛,如互动课堂、语聊房、多人相亲、1v1 社交、近程会诊、在线 KTV 等。RTC 技术的低延时、无卡顿、高清晰、无损音质在这些不同场景外面的需要,是各有偏重的,比方泛娱乐的语音社交、娱乐直播等更强调低延时和无卡顿;在线教育场景,对画质清晰度要求极高,并且还要有教学白板、举手发问这样的实现特定场景的性能;近程会诊如需在线看片,则对音视频清晰度和晦涩度均有较高要求,而钢琴教学、管弦乐等音乐教学场景,对无损音质的需要强烈。 据理解,融云的 RTC 技术当初每两周迭代更新,可为开发者提供规范的 SDK:音频声音清晰间断,无显著乐音,最大抗丢包可达 80%;视频应用 1080P 超高清分辨率,最大抗丢包 40%,语音提早小于 120 ms,视频提早小于 200 ms。这样的技术标准可满足上百种场景的需要。 ...

April 19, 2021 · 1 min · jiezi

关于音视频:如何抓住新社交风口下的音视频通讯大潮

随着新一代年轻人逐步走上前台,互联网生态也面对着全新的挑战。 在2017年由羊城晚报、华南理工大学和中山大学联结公布的《粉红 z 世代——中国 95 后数据报告 》中提到,作为“421 家庭”模型成长起来的独生一代,高竞争感和高孤独感两大因素集中在一起使得 95 后比上一代人出现更多的心理案例。 对 95 后大学生抑郁状况的问卷调查结果显示,56% 的 95 后大学生样本体现出不同水平的抑郁,其中 40% 的 95 后大学生有轻度的抑郁,12% 的 95 后大学生有中度的抑郁,4% 的 95 后大学生甚至有重度抑郁的状况。 在这样的背景下,虚构男友、在线陪伴……年轻人的孤独感正在成就一个百亿级以上的“陪伴经济”市场。全新的社交模式在轻轻造成,由此而产生的大量不同于以往的社交产品。 也正是瞄准了新一代年轻人的需要,抓住了女性精力生产的潜在需要,以面向年老女性用户群体的在线陪伴社交平台——「甜味陪伴」迅速崛起。 「甜味陪伴」超过 QQ 小红书,融云提供全方位助力 针对女性在成长和生存中容易产生孤单、焦虑、抑郁等情绪,「甜味陪伴」提供了一对一的陪伴社交服务,包含虚构恋人、树洞倾诉、失恋陪护、心理陪护、失眠陪伴等多样化的陪伴场景。 这一产品理念失去了泛滥投资人的认可,并取得了包含 Soul 的天使投资人杜欣、元气森林创始人唐彬森的挑战者资本等在内的战投投资。并于往年 3 月实现了千万级人民币的 Pre-A 轮融资,投资方为泥藕资本和简鸣资本,追光资本负责独家财务顾问。 仅上线半年工夫的「甜味陪伴」,现已领有近百万注册用户,其中 80% 以上是女性用户,用户复购率约 55%,付费用户日应用时长 1.5 小时。3 月 23 日,该产品一度登上 App Store 社交排行榜第二的地位,仅次于微信,甚至超过了 QQ 和小红书。 「甜味陪伴」为用户提供一对多的语音聊天室性能,涵盖情感电台、情绪树洞、女性成长、星座占卜等女性向主题,满足一对多实时互动场景的需要。 为了向用户提供更高质量、多元化的社交服务,「甜味陪伴」选了寰球互联网通信云服务商融云,作为其实时音视频和即时通讯的性能合作方。 作为对 RTC 和 IM 都有较高要求的产品,甜味陪伴 CTO 张波示意,在对市面上的多个同类产品进行比拟之后,发现融云的 RTC 和 IM 在稳定性、低提早、丢包率等方面的综合实力十分突出。同时,融云的 SDK 的应用办法较为简单,不便上手,极大的加重了开发和经营压力。 另一方面,「甜味陪伴」还笼罩了美国等地的大量海内市场用户,融云通过其笼罩寰球用户的稳固服务能力,为「甜味陪伴」拓展海内市场提供了弱小助力。 ...

April 2, 2021 · 1 min · jiezi

关于音视频:融云推出超值套餐包音视频20万分钟免费享

3月,寰球互联网通信云厂商融云官网上线“春暖花开流动季”,面向互联网开发者推出“史上超值”套餐包:但凡开明实时音视频性能的用户,立享每月收费200,000分钟。该流动的收费分钟数音视频通享,视频最高可反对1080P 超高清分辨率。 融云实时音视频产品 超值套餐包 据理解,此前该套餐包为980元包月,内容含音视频产品收费10,000分钟。当初降级后的套餐包是之前收费分钟数的20倍,流动长期有效,每月购买都可享超值套餐服务。 融云回馈音视频新老用户 实时音视频能力卓越 以后,音视频赛道玩家泛滥,各通信云厂商在品质、价格、服务方面开展全方位的比拼,这使得宽广开发者获益匪浅。融云此次降级产品套餐包,目标在于给新老开发者提供性价比最高的产品与服务。在等同价格下,对于初创企业来说,尚处于产品经营起步期,日活量和用户数都不是很高的状况下,相当于近乎零老本地应用融云高品质的音视频产品。 对于成熟经营的App来说,往往须要采纳1080P超高清分辨率的视频画面,能力满足用户留存和日活量的需要,而以后,通信云服务商对于视频分辨率的反对水平,广泛与计费形式成正比,如果要失去高清分辨率的视频产品,则须要额定付费,或者通过升高收费的分钟数折算。据理解,如果当月全副应用20万分钟的高清分辨率音视频产品,其余通信云服务商的价格高达数万元。融云正是看到这一市场现状,率先被动降级产品套餐包,一举解决这一痛点需要。对所有开发者来说,这无疑极大升高了企业老本压力,无论标清、高清、还是超高清,一律每月收费畅享200,000分钟,以满足最终用户对高清视频日益增长的体验需要。 目前,开发者应用融云能够 30分钟疾速集成音视频能力。在音视频服务上,融云反对一对一、多对多音视频通话、服务端录像。针对音视频会议直播场景,融云反对高质量的多人会议,帮忙开发者疾速取得晦涩稳固、多端互通的网络通话体验;对于低提早直播的场景,融云音频声音清晰间断,无显著乐音,最大抗丢包可达80%,视频最大抗丢包40%;语音提早小于120 ms,视频提早小于 200 ms,语音直播提早小于350 ms,视频直播提早小于350 ms,保障端到端之间提早无感知的实时互动。 并且,融云实时音视频服务曾经全面适配市场支流的各类终端设备,笼罩 iOS、Android、Web、小程序、Windows、macOS、Linux、Electron 等多类型平台,反对平台间互通,全面保障实时音视频在各类终端上的良好利用。 融云以RTC+IM的双重技术劣势 立足提供全球化的开发者服务 除了音视频产品外,融云还领有实力卓越的 IM 产品线。据艾瑞征询《2020 年寰球互联网通信云行业钻研报告》显示,融云间断6年领跑 IM 市场,笼罩的 APP 日活设施数加总(非去重)超过 5000 万台,居国内第三方厂商的首位,是业界惟一承诺音讯不丢、不重、不乱序且 100% 达到的通信云厂商。 因而,抉择融云RTC产品的开发者,将真正体验到物超所值的融云“RTC+IM”双重服务,因为,融云实时音视频的通信架构以高牢靠的 IM 信令保障为前提,RTC 复用 IM 底层信令通道,可使业务在稳定性、连通性、并发/负载等方面服务可用性达到电信级 99.99%。同时,融云还提供Push推送服务,可简略疾速实现利用内的零碎告诉和站内揭示模块,不便业务经营,晋升留存率和召回率。 融云始终认为,通信品质的保障是掂量技术水平的标尺。在各类应用场景中,终端之间的每一条信息传递都须要通过信令被唤醒,因而信令的稳定性和可靠性对于低延时、高质量的 RTC 通信尤为重要。融云的外围价值是以“一套 SDK 满足所有通信场景”,针对不同场景的简单个性化性能需要,融云力求通过一直进化的架构,让开发者简略便捷地集成互联网通信能力。这种由同一云厂商提供的双重通信能力,能够无效缩短开发上线周期,升高开发者的学习老本,进步应用满意度。 此外,融云立足于提供全球化的开发者服务,在寰球领有多个数据中心、3000+动静减速节点,联合自研的最优链路调度算法,能够解决跨国、跨运营商、大规模用户拜访导致的响应慢、丢包高、服务不稳固等问题。在标准化服务方面,融云提供实时监控体系、1对1商务全程反对,7x24 小时服务保障等,并且融云还是业界惟一承诺工单1小时回复的通信云厂商。 目前,融云服务的互联网客户有:汽车之家、易车、万科、失去App、乐学、伴伴、享物说、斗米、千丁、荔枝、蜻蜓FM、百姓网、中原地产、新浪二手房、悦跑圈、天天狼人杀、豆果美食、英语趣配音、土巴兔、挪动电影院、天籁K歌、编程猫、核桃编程、六间房、IDG、华兴资本、诸葛找房、丽兹行、蜜芽、寺库等。 融云以RTC+IM双重能力 服务寰球开发者 据悉,融云推出的“史上超值”套餐包流动,曾经能够在官网“春暖花开流动季”页面查问到,开发者们扫码即可开明此服务,机会难得,大家赶快口头起来吧!

April 2, 2021 · 1 min · jiezi

关于音视频:融云XMeetup南京站-探讨实时通信架构的高质量设计

2021年3月7日,融云X-Meetup技术沙龙第二站落地南京。这场以“高质量高并发的实时通信架构设计与摸索”为主题的开发者流动,邀请到融云音视频工具研发工程师王炜、IM 高级研发工程师齐新兵、壳壳互联软件工程师张熙文、虎克CEO过巍四位大咖,向现场的开发者们分享了各自畛域的干货。 融云X-Meetup技术沙龙 南京站现场 音视频SDK架构设计,重在稳固牢靠 沙龙上,融云音视频工具研发工程师王炜首先发表了《融云音视频 SDK 架构分享与利用》的演讲。他认为,谈到 SDK 架构设计,融云音视频 SDK 因简洁易用、通俗易懂、可分层架构、可替换可复用、易于保护等诸多长处,为广为开发者所熟知。这既是融云音视频SDK架构设计的经验总结,也是融云音视频SDK架构设计的总准则。 目前,融云音视频SDK架构次要由API接口层、数据模型层、会话管理层、根底组件层和信令层组成。在数据模型层,设计应面向业务逻辑、面向用户,要关注数据模型不同的生命周期,兼顾读凋谢、写限度。尤其不可漠视的是要做好保护性拷贝,以便后续的经营保护。 融云音视频SDK架构 在分享会话管理层的设计要点时,王炜间接以框架设计图来阐释音视频采集、前解决、编码、传输、解码、后处理、渲染各状态相互之间的逻辑关系。简捷而直观的表白,帮忙开发者更好地了解其设计的精华。 会话管理层正当设计架构 在根底组件层,王炜指出,因其面向底层设施硬件资源,是一个独立的工作管理系统,因而要更重视模块性能的内聚,具备非间接耦合和接口隔离;而信令层的设计,则要求可能封装IM信令通道和进行Http申请,使之具备独立于业务性能的逻辑,不仅要有根本的通信能力,还可拆包、封包,并且不容许跨层调用。 大规模即时通讯客户端日志零碎,重在发现问题 目前,融云 SDK 服务 30 万款 App, 总触达数超过 50 亿,日均音讯量冲破 150 亿,日均沉闷用户 7000 万,日音讯峰值高达 2218 亿条,秒峰值音讯 2000 万条。这些数据实实在在地见证了融云大规模通信架构的高光时刻。 在高光时刻的背地,融云IM 高级研发工程师齐新兵坦言,“当一秒钟要实现 2000 万条音讯的散发时,不只是咱们本人的研发、运维团队,甚至是咱们运营商、机房的人都时刻在放心各种意想不到的故障。”因而,可能先于客户发现问题,并及时发现本身问题,确保以高质量的 SDK 服务客户,融云大规模即时通讯客户端日志零碎就显得极为重要。 是否残缺、及时地把零碎中呈现的问题反馈进去,并在成功率和可视化方面领有出众体现,是大规模即时通讯客户端日志零碎设计的次要诉求。灵便管制日志上传、保障挪动端日志对立、保障上传成功率,以及标签日志黑名单性能,这些都是日志零碎设计和降级要点。 例如,要做到灵便管制日志上传,应依据每家客户利用下发日志配置,满足不同的平台和版本,要设置好上传工夫距离和失败重试次数,确保日志上传的成功率和及时性。同时,还要做到灵便管制被动上传和被动上传,以便有针对性地排查问题:被动上传含日志开关与上传级别,不便敞开与管制;被动上传则可拉取指定用户特定时间段内的所有日志。 在设计中,保障挪动端日志对立,则能无效保障日志的可视性和完整性。此外,正当利用日志标签黑名单性能,使黑名单内的日志不再入库上传,在实践中可极大缩小日志量,从而加重服务器的老本压力。 直播社交 依附融云高质量通信架构的设计 作为X-Meetup技术沙龙流动的“X”嘉宾,虎克CEO过巍分享了公司的倒退历程及直播行业对PaaS通信云能力的需要。虎克自2012年开始进入商业直播畛域,其模式次要是会议直播,这与当初常常看到的娱乐直播和秀场直播都不同,差别在于视频格式、物理环境不同,线上会议直播与线下内容的交互更强关联,因而对实时性的要求也比拟高。随后,虎克进入了秀场直播畛域,比方线上抓娃娃,直播社交等多种利用场景。 在公司倒退过程中,虎克看到了越来越多有商业价值的利用场景都须要底层通信技术赋能,而想要领有稳固牢靠的通信云能力,不是一家初创公司花半年甚至一年工夫,找十几个、二十几个工程师可能做得进去的。 为了疾速倒退,虎克最终抉择与融云牵手单干。单干后,虎克负责利用场景和商业价值的实现,而所有与底层通信云相干的技术与服务都交给融云。目前,虎克已推出60多款利用产品,笼罩超过90%的典型场景,繁多利用产品用户量曾经冲破百万。最为难得的是,所有利用产品用户体验是零投诉,这齐全依赖于融云稳固、牢靠的高质量高并发的实时通信架构。 此外,直播社交畛域的壳壳互联软件工程师张熙文也分享了《直播社交零碎架构降级》的最佳实际,认为用户感知和视觉体验应成为架构降级过程中,重点被解决的问题,并以视觉体验中的主题皮肤设计为例,具体向开发者介绍了该设计的框架技术图。 结语 娱乐社交、电商直播等利用场景,都须要音视频和IM外围性能来撑持,而行业红利的暴发,用户规模的指数级增长,又须要一直降级迭代的架构来保障用户体验。因而,把握高质量高并发的实时通信的架构设计越来越成为开发者的必备技能。融云X-Meetup南京站技术沙龙,为开发者提供了交换的平台与机会,期待2021年下一站再相遇。

April 2, 2021 · 1 min · jiezi

关于音视频:安卓推送一体解决方案

一、背景 作为 IM 的根底能力之一,推送的重要性显而易见,它是手机操作系统提供给利用触达用户的重要伎俩之一。苹果零碎有 APNS,谷歌也为安卓零碎提供了零碎级别的推送服务 FCM。 然而,因为 FCM 在我国无奈应用。利用为了保障用户能收到重要音讯,进步本身的拉活率,晚期的时候很多利用都是自建推送通道,通过各种保活措施或者频繁拉活来确保通道存活,这就导致了手机零碎内很多服务无奈回收,耗电和发热问题突显,成为安卓手机的一大诟病。 为了晋升本人的用户感知,谷歌及国内各手机厂商对利用权限的管控越来越严,没有用户的许可,自建通道根本不可能存活。但用户对推送服务的需要又是的确存在的,为了满足这个需要,各手机厂商纷纷推出了本人的零碎级别推送服务。 二、现状 目前国内有零碎级别推送的次要厂商如下:华为、小米、OPPO、vivo、魅族。 因为各厂商的推送策略和集成形式各不相同,开发者须要钻研各家文档,一一适配,开发门槛高且琐碎。如果有出海需要的利用,还须要对 FCM 独自适配,最多的状况下一个利用可能须要适配多达六个推送通道,开发成本极高。 三、融云解决方案 针对以上问题,融云 SDK 对接了各厂商推送,配合搭建的自有推送通道,智能抉择最优计划,最大水平保障了推送达到率。 另外 SDK 还对各厂商推送接口进行了提炼和合并,开发者只须要几行代码即可实现全通道推送能力,极大升高了开发成本。通过提炼后的对立接口,开发者能够很不便的进行告诉自定义和事件监控。 融云推送计划 依据客户端和服务端的交互过程,从以下三点对融云推送计划进行阐明: 协商通道过程通道抉择策略承受推送过程协商通道过程 客户端初始化时,依据本地保留的配置状态决定是否须要和推送服务交互。 若没有实现配置,客户端首先和推送服务建设长连贯,并和服务协商须要应用的推送类型,而后依据服务返回的类型调用对应的第三方注册接口,并将获取到的 token 发给服务,至此,协商结束,断开长连贯通道。 若配置曾经实现,则间接向第三方推送服务进行注册,获取到第三方推送服务返回的 token 后和本地缓存进行比对,如果不统一,才将新 token 发给融云推送服务,否则不进行任何解决,免得资源节约。 补充阐明一点,协商后如果确认应用融云自建通道,SDK 会在独自的推送过程再次和服务建设长连贯,并放弃后盾存活。 通道抉择策略 a. 优先应用零碎级通道。客户端首次初始化时,将利用所反对的推送类型和以后设施信息发送给服务端,IM 推送服务联合两者信息以及后盾配置信息一一匹配,优先返回和设施匹配的零碎级推送通道。 b. 海内用户优先应用 FCM。鉴于谷歌原生推送(FCM)的固有劣势,针对海内用户,融云进行了非凡解决。当用户出访 IP 为海内地址时,优先应用 FCM 通道。 c. 自建通道作为保底伎俩。如果没有匹配的零碎级别推送时,融云会启用自建推送通道 RongPush, 以最大水平保障推送达到率。 承受推送过程 融云推送服务接管到一条音讯后,若指标用户离线,则依据协商过程中所应用的推送类型,将音讯推送给对应的第三方,第三方推送服务通过本人的零碎级推送通道,将音讯送达到目标用户设施,并在告诉栏展现。 客户端应用阐明 1. 配置示例 PushConfig pushConfig = new PushConfig .Builder().enableFCM(true) //配置 FCM 推送 .enableHWPush(true) //配置华为推送 .enableMiPush(MI_APPID, MI_APPKEY) //配置小米推送 .enableMeiZuPush(MEIZU_APPID, MEIZU_APPKEY) //配置魅族推送 .enableVivoPush(true) //配置 vivo 推送 .enableOppoPush(OPPO_APPKEY, OPPO_SECRET) //配置 OPPO 推送 .build();RongPushClient.setPushConfig(pushConfig); //配置推送 ...

March 26, 2021 · 1 min · jiezi

关于音视频:融云2021-XMeetup启航-探索高并发下的高质量实时通信架构设计

2021年3月20日,融云X-Meetup技术沙龙首站在重庆启航。本次沙龙,融云WebRTC开发工程师苏道、壳壳互联软件工程师张熙文、融云IM高级研发工程师齐新兵、探探科技国际化技术负责人王伟四位技术大咖,围绕如何实现“高质量高并发的实时通信架构的设计”这一主题,向开发者们分享了贵重的实践经验。 X-Meetup技术沙龙:重庆站 融云《大规模音视频会议实际》和《大规模即时通讯客户端日志零碎实际》的演讲,别离从RTC和IM通信云全线产品,向开发者介绍了超大规模会议场景优化策略、如何做好日志零碎及成果评估,解答了开发者对于底层通信架构设计的困惑;壳壳互联和探探科技也各自分享了在实践中的系统优化策略。 大规模音视频会议的通信架构优化设计策略 疫情突破了空间的局限,音视频会议越来越广泛,大家接收并更习惯了线上会议的便捷性。进入2021年,随之而来的一个变动就是,大规模以及超大规模(500人)的音视频会议需要悄悄在增长。 在超过20 人会议场景下,现有的多对多网络架构SFU 与 WebRTC 的兼容场景就无奈很好地解决。如果500人的会议,间接抉择参会人之间进行音视频互动,音视频数据的齐全转发对服务器资源的需要是微小的,再加上会议中有大量人员同时接入,服务端上行流量和上行流量陡增,更加剧了服务器资源的压力。 融云WebRTC开发工程师 苏道 现场答疑 在不稳固的网络环境中,要解决上述问题,同时还要保障通信品质的稳定性,最基本的计划是设计正当的通信架构。融云苏道分享道,能够通过按需订阅与转发、优化音频流量两种策略优化通信架构,在保障成果的前提下,将极大缓解服务器的压力。 具体来说,按需订阅与转发策略应做到以下几点:第一、反对独自订阅某个人的某路视频或某路音频;第二、接收端仅订阅正在谈话的人的视频,音频全副订阅;第三、按需订阅视频大小流。目前,融云 SDK 反对发送端视频编码,反对大小流、接收端按需订阅大流或小流。大流的清晰度高,码率高;小流的清晰度低,码率低。这样当接收端想观看清晰视频的时候订阅大流;对清晰度要求不高的时候订阅小流。另外,弱网下融云反对主动切换大小流,以保障视频的流畅性。 优化音频流量策略,升高音频流量则次要应做到:第一、发送端静音时不发送数据;第二、调整音频码率;第三、服务器下发音量 Top N 路。个别状况下,客户端收到音频流,在音频解码后,默认仅混流播放音量最大的 3 路声音。因而肯定要防止不必要的音频包的转发,以缩小服务流量,只有无效音频包,才会进入到上行散发队列。 除此之外,为了优化音频体验,还需注意级联状况的解决、大会议室房间和一般房间之间的切换等多个方面。最初,苏道激励开发者道,“架构从没有失败和胜利之说,都是先做得进去且可能用,而后再进一步优化迭代,满足更多人、更多场景的须要。” 大规模即时通讯的客户端日志零碎实际 日志是记录零碎中各种问题信息的要害,大规模即时通讯的客户端日志零碎蕴含了海量数据。随着业务的倒退与增长,日志平台也要经验迭代降级。绝大部分开发者对日志零碎的要求是:完整性、及时性、上传成功率、以及可视性。 针对以上诉求,融云IM高级研发工程师齐新兵分享了日志零碎如何降级的实际。他认为,日志零碎首先要做到灵便管制日志上传。依据每家客户利用下发日志配置,日志上传工夫最好距离在10秒左右,并容许上传失败重试5次,以确保日志上传的及时性和上传的成功率;同时还要有被动上传和被动上传机制,以不便针对性的排查问题。 其次,保障挪动端日志对立。这须要对立编写日志模块,保障逻辑对立;梳理标签,保障日志标签内容统一;对立编写底层数据库模块,数据格式要两端统一,从而无效保障日志的可视性和完整性。除此之外,还要有日志标签黑名单性能,黑名单内的日志不再入库,不再上传,肯定水平上缩小日志量,加重服务器的老本压力。 日志最重要的意义在于先于客户发现问题,同时也可能及时发现本身问题,确保以高质量的 SDK 服务客户。因而,齐新兵认为,大规模即时通讯的客户端日志零碎在研发过程中,须要多测试,不怕裸露其中的问题,能力晋升开发者体验。 直播社交及社交的零碎架构实际 在直播社交畛域,壳壳互联软件工程师张熙文分享了《直播社交零碎架构降级》的最佳实际,他认为,影响直播社交日活的重要指标是用户感知和视觉体验。简略说,用户感知就是如何缩小提早,实践上直播提早超过150-200ms便能够被人脑感知。实际中,壳壳互联在服务端和客户端别离进行技术协定和技术计划的优选,最终达到接口申请速度减少20-40%、单位工夫内服务器申请承载量减少30%左右,用户在直播社交中的感知速度晋升。 直播社交受众对视觉体验的要求更高,这次要指主题皮肤的框架设计,包含正当批改UI元素的属性、从新布局特定UI元素、可经营主题皮肤、可发售主题皮肤等,因而,张熙文特地分享了主题皮肤的设计框架技术图,启发开发者从中取得新的思考。 壳壳互联张熙文分享主题皮肤的设计框架技术图 此外,探探科技国际化技术负责人王伟也带来了《基于探探IM零碎的优化分享》。从探探IM架构、接入层、转发层和服务层、通信协议、告诉机制等不同方面介绍了探探对高并发下的高质量实时通信架构设计的摸索。 X-Meetup技术沙龙下一站:南京 X-Meetup技术沙龙是融云2020年组织发动的,围绕"寰球通信云技术的倒退与摸索" 为主题,每期邀请特定行业的技术大咖作为神秘“X”人,与融云一起分享开发者最为关怀的前沿技术和最佳实际。往年首站重庆启航后,下一站3月27日南京站正在炽热报名中,融云期待与开发者们共叙音视频实战的窘境和解决之道,报名到会的开发者,还将享有专属惊喜礼品,以及与“X”技术大咖独自交换的机会。

March 26, 2021 · 1 min · jiezi

关于音视频:融云-Web-播放声音-Flash-篇-播放-AMRWAV

本文次要介绍 Flash 播放 AMR 格局 Base64码 音频。 在此之前么有接触过 Flash ,接触 AS3 是一头雾水,不过幸好有 TypeScript 和 JavaScript 的根底看起来不是很吃力,现学现卖的就是开了 ”跳坑“ 之旅~~~ 1、实现思路 起初一点实现思路都木有,不晓得该从何做起,只晓得用 Flash 播放 AMR ,度娘谷姐的一顿找,后果可想而知,没有蹩脚,只有非常蹩脚,哈哈。 起初想了想,凡事都得有个思路,不能闷头干,霎时豁然开朗,为本人节约的快一天的工夫,感到惭愧和胆怯..... ① Flash 都能播放哪些音频。 ② 在 ActionScript 中AMR 是如何转换成 Flash 可播放的音频的。 ③ JS 中如何调用 ActionScript 中办法,如何交互。 ④ 如何把 SWF 文件嵌入到 HTML 页面中。 ⑤ 如何把 AMR(Audio) 和 Flash 播放AMR 两种形式封装起来。 2、逐个破解 ① Flash 都能播放哪些音频: MP3 格局是 Flash 默认反对的音频格式,WAVE 格局须要转换能够播放,其余格局也是须要转换的,因为先做的 Chrome 下播放声音,对 WAVE 音频多少有些理解,所以决定从 WAVE 音频动手,所以依照上述的套路来 ”屡思路“: ...

March 18, 2021 · 4 min · jiezi

关于音视频:融云-Web-播放声音AMR-WAVE

最近甚是苦闷,做语音播放降级,跳进了很多坑,别提有多惨了,不过后果还是不错滴,纵观前后,一句话足以概括 “痛并高兴着” ~~~ ok,我少说废话,上面来总结下 Web 播放声音一些注意事项。 说到 Web 我第一件事想起的就是浏览器兼容性,播放声音当然也难逃苦海,须要留神以 Trident 为内核 (IE为主) 的浏览器,和 FF、Chrome等浏览器的区别。 1、技术筹备 ① FF、Chrome等反对<Audio>的能够应用 github 上 AMR 开源库进行播放,次要用到 pcmdata.min.js、libamr-nb.js、amr.js 三个js,后续会具体介绍。 ② IE 浏览器下不反对(IE9以下<Audio>) 、(IE10 以下不反对 AMR解码中用到 Blob 对象),所以须要用 Flash(AS3.0) 进行播放。 2、具体阐明 为防止文章过于简短,针对以上两种状况别离总结: ① 应用 AMR (Audio) 播放 : http://www.cnblogs.com/yuhongda0315/p/5224188.html ② 应用 Flash 播放 :http://www.cnblogs.com/yuhongda0315/p/5224450.html 3、材料下载 ActionScript : player-as3源码.rar 残缺的demo : amrPlayer-jsdemo.rar ActionScript 播放 Wave 文件 :wavePlayer-as3源码.rar 所须要的JS(amr.js 在 libamr-min.js 最下方):所需JS.rar 原始文章连贯:https://www.cnblogs.com/yuhongda0315/p/5224064.html 融云官网:https://www.rongcloud.cn 融云文档:https://docs.rongcloud.cn/v4

March 18, 2021 · 1 min · jiezi

关于音视频:融云-AMRAduio-播放-AMR-格式-Base64-码音频

1、必备材料 github AMR 开源库 :https://github.com/jpemartins/amr.js 用心把这个我的项目看一遍,对于我上面说的话,能够疏忽啦,代码是最好的文章,哈哈~~ 2、外围 JS 库 :amr.js 、pcmdata.min.js、libamr-nb.js (g上述ithub我的项目中有另外三个js,我给合成一个amr.js,不要凌乱)这三个 JS 是播放声音的次要依赖,上面一 一 介绍下: ① amr.js : 能够了解成 “桥” 的概念,连贯底层解码和客户端调用的桥梁。 ② pcmdata.min.js : 封装 pcm data, PCM是一种编码格局 , PCM 增加上 RIFF 头 能够组成 Wave 音频(Wave 不止这一种编码方式),细节太深,小弟也不懂啦~~,有空深挖。 ③ libamr-nb.js : amr转换的外围库,这个文件比拟大,压缩后大略也要 600kb 左右。 ④ 如果下载三个外围库,倡议从上篇 “Web 播放声音 — 介绍篇” 中的附件中卸载,在 github 当初的外围库,在 Chrome 下只能播放一次,把这个问题修复了一下,起因是以同样的 Audio.src 创立 Audio 在 Chrome 下就不能二次播放,网上说法各异,最终本人入手解决了,具体能够在 amr.js 中的 global.util.play 办法中看。 3、具体用法 说了有一阵子文言了,该上点代码了,上面是我封装的播放 AMR 格局 Base64 码 的插件,间接在页面援用能够 ,下载地址能够在 “Web 播放声音 — 介绍篇” 下载。 ...

March 18, 2021 · 3 min · jiezi

关于音视频:融云发送语音消息

最近在集成融云 IM SDK,但官网提供的语音不蕴含录音能力,所以本人做了一个浏览器录音并播放的 Demo,有须要的小伙伴能够拿去耍~~~ 录音工具是 HTML5 的 getUserMedia,所以顽固派浏览器天然就木有方法反对了,好的,废话太多了,getUserMeida 录音的故事马上开始了。 实现思路1、应用 getUserMedia 须要思考各个浏览器的差别,具体差别请移步:https://developer.mozilla.org/zh-CN/docs/Web/API/Navigator/getUserMedia 2、应用 WebWorker 来解决录音及音频转换。 3、转为 Base64 格局的 WAV,用于浏览器播放(此处须要留神,能够转换 Blob 间接播放,此处为了阐明转换音频的接口,所以转为 Baes64)。 具体实现1、开始录音:RongRecorder.record(); 调用此办法开始录音。 2、进行录音:RongRecorder.stop(); 调用此办法进行录音。 3、进行并导出:RongRecorder.stopAndExport(type,callback); 调用此办法进行并导出音频为指定的 type 类型(尽管目前只反对 Wave,为了后续的扩大嘛~~~)。 4、导出:RongRecorder.exportRecord(type); 导出指定 type 类型的音频流。 5、清空本地音频流:RongRecorder.clear(); 演示1、兼容 getUserMedia 代码片段 navigator.getUserMedia = navigator.getUserMedia ||navigator.webkitGetUserMedia ||navigator.mozGetUserMedia; 2、WebWorker 代码片段 this.onmessage = function(e){ switch(e.data.command){ case 'init': init(e.data.config); break; case 'record': record(e.data.buffer); break; case 'exportRecord': exportRecord(e.data.type); break; case 'clearRecord': clearRecord(); break; }};function init(config){ sampleRate = config.sampleRate;}function clearRecord(){ recBuffersL.length = 0; recLength = 0;}function record(inputBuffer){ recBuffersL.push(inputBuffer[0]); //recBuffersR.push(inputBuffer[1]); recLength += inputBuffer[0].length;}function exportRecord(type){ var bufferL = mergeBuffers(recBuffersL, recLength); var interleaved = interleave(bufferL); var dataview = encodeWAV(interleaved); var audioBlob = new Blob([dataview], { type: type }); this.postMessage(audioBlob);} ...

March 18, 2021 · 1 min · jiezi

关于音视频:融云-CallLib-集成遇到的问题

近期选用融云音视频产品实现相似微信的通话性能, 通过几天的调试, 终于实现了基本功能, 以下总结集成中遇到的问题 查看文档首先先查看融云的文档, 介绍不是很具体, 如果不参考 Demo, 集成起来还是比拟艰难 但有一个亮点, 文档内就间接能体验融云 CallLib 的成果 融云 CallLib 文档: https://docs.rongcloud.cn/v4/views/rtc/call/noui/intro.html Demo 参考Demo 找到两个. 代码都很简略, 没有太多业务代码, 参考起来比拟敌对 文档中的 Demo: https://github.com/rongcloud-snippets/web-call-quickstart 教程中的 Demo: https://github.com/rongcloud/websdk-demo/tree/master/calllib-v3/ 教程类 Demo 蕴含一个残缺的启动教程, 可参考: https://tutorials.rongcloud.cn/tutorial/web-calllib-demo#0 遇到的问题1、未找到错误码的残缺解释 在文档中搜寻多遍, 都没有找到错误码的列表. 提工单询问后, 得悉只有旧文档中有解释. 新文档还正在增加中 旧文档: https://docs.rongcloud.cn/rtc/calllib/web/code/ 2、单对单通话, 一方挂断, 另一方必须也调用挂断办法 设计有些不合理. 应该是思考兼容多人音视频, 心愿单人、多人调用形式保持一致 3、Web 多端登录时, 须要额定解决错误码 8 如果同一个用户在 Web1、Web2 同时登录, 如果用户收到音视频呼叫, Web1 接通后, Web2 会主动挂断, 并抛出一个挂断码 8. 此处逻辑须要额定解决, 给客户一个提醒近期选用融云音视频产品实现相似微信的通话性能, 通过几天的调试, 终于实现了基本功能, 以下总结集成中遇到的问题 查看文档首先先查看融云的文档, 介绍不是很具体, 如果不参考 Demo, 集成起来还是比拟艰难 ...

March 18, 2021 · 1 min · jiezi

关于音视频:集成融云-Web-音视频通话踩坑之旅

前言最近有个我的项目须要应用的融云的 CallLib SDK 实现相似微信的视频通话,所以在我的项目还未正式启动的时候,我曾经偷偷的开始进行集成了,免得到时候不熟一顿加班那真的欲哭无泪了,好消息就是我曾经应用过融云家的 IMLib SDK 做过即时通讯的性能,所以整个注册流程和开发者后盾的应用曾经比拟熟了,当然,即时不熟也没关系,跟着他们的文档一步一步来,也能很快的就上手了。 融云官网:https://www.rongcloud.cn/ 上面是集成的时候碰到的一些须要留神的问题: 1、Web 站点必须为 localhost 或 https 2、必须胜利连贯 IM 后, 才可进行 CallLib 通话 3、新版谷歌浏览器(86版本)会报错,我集成的 RTC 版本是 3.2.3 4、音视频通话接通不了 综上问题,我会逐个解答,对于具体的集成能够间接参考:https://docs.rongcloud.cn/v4/views/rtc/call/noui/quick/web.html 还有具体的 demo 也能够参考一下 https://github.com/rongcloud-snippets/web-call-quickstart Web 站点必须为 localhost 或 https: 这个是融云的应用音视频通话的前置条件,原本在本地调试的时候好好的,可是公布到线上的时候就不能用了,最初提交工单询问融云的技术人员上线是否还须要配置什么,最初排查一圈发现生产环境应用的站点是 http(欲哭无泪。。。),童鞋们引以为戒啊!! 必须胜利连贯 IM 后, 才可进行 CallLib 通话: 间接看代码: // appKey 可在融云开发者后盾获取const im = RongIMLib.init({ appkey: '<your-appkey>' })// 增加事件监听器im.watch({ // 连贯状态监听 status(evt) { console.log('连贯状态码:', evt.status); }, // 音讯监听 message(evt) { console.log('收到新音讯:', evt.message); }})// CallLib 初始化var config = { timeout: 20000, RongIMLib: RongIMLib, RongRTC: RongRTC};rongCallLib = RongCallLib.init(config);//token 可从开发者后盾获取 或 Server APIconst token = ''im.connect({ token }).then(user => { console.log('链接胜利, 链接用户 id 为: ', user.id);}).catch(error => { console.log('链接失败: ', error.code, error.msg);}); ...

March 18, 2021 · 1 min · jiezi

关于音视频:融云如何把图片消息的图片上传到自己的文件服务器

咱们应用融云开发的我的项目, 但咱们有一个需要是, 把图片不要上传到融云的服务器, 而是本人的服务器.于是就征询了一下技术支持. 被告知有一个接口办法齐全能够满足咱们的需要. ImageMessage imageMessage = ImageMessage.obtain(Uri.parse(FILEPATH), Uri.parse(FILEPATH)); configSendMessage(imageMessage); Message message = Message.obtain(mTargetId,mConversationType,imageMessage); RongIM.getInstance().sendImageMessage(message, "pushcontent", "pushdata", new RongIMClient.SendImageMessageWithUploadListenerCallback() { @Override public void onAttached(Message message, RongIMClient.UploadImageStatusListener watcher) { // 这里是本人上传图片的逻辑, 图片的门路能够通过 message 中进行获取. //watcher 这个参数次要是用于把本人的上传状态同步给 sdk. 这样咱们就能够应用 sdk 外部的默认逻辑, 包含界面. } @Override public void onError(Message message, RongIMClient.ErrorCode code) { } @Override public void onSuccess(Message message) { } @Override public void onProgress(Message message, int progress) { } }); ...

March 15, 2021 · 1 min · jiezi

关于音视频:唠一唠融云-VIVO-push-无法跳转的解决方案

在集成融云SDK 的过程中,不可避免的是要收到推送,因为为了保障达到率,所以集成了融云的厂商推送,在集成之后,发现个问题,VIVO 推送收到告诉栏之后点击是无奈进行跳转的,通过征询融云的技术同学,解决了此问题。 以下是解决此问题的解决方案,记录在此,以供大家参考; 首先须要复写 VivoPushMessageReceiver ,而后在 onNotificationMessageClicked 办法中进行捕获; public class MY extends VivoPushMessageReceiver {@Overridepublic void onNotificationMessageClicked(Context context, UPSNotificationMessage message) {PushNotificationMessage pushNotificationMessage = transformVivoToPushMessage(message.getTitle(), message.getContent(), message.getParams());if (pushNotificationMessage != null) {PushManager.getInstance().onNotificationMessageClicked(context, PushType.VIVO, pushNotificationMessage);} } 2 . 其中 transformVivoToPushMessage 办法能够齐全照抄我一下的办法。 public static PushNotificationMessage transformVivoToPushMessage(String title, String content, Map<String, String> params) {if (params == null){ return null; } PushNotificationMessage pushNotificationMessage = null;String rc = params.get("rc");if (rc != null) {try {JSONObject rcJson = new JSONObject(rc);pushNotificationMessage = new PushNotificationMessage(); ...

March 15, 2021 · 1 min · jiezi

关于音视频:融云如何更换用户信息

在融云的用户信息机制中,是由用户信息提供者设置的用户信息,当然为了信息安全,用户信息的保护留在咱们本人的服务端进行操作的; 首先,参考融云文档 设置用户信息提供者。 RongIM.setUserInfoProvider(new RongIM.UserInfoProvider() {/** 获取设置用户信息. 通过返回的 userId 来封装生产用户信息.@param userId 用户 ID*/@Overridepublic UserInfo getUserInfo(String userId) { UserInfo userInfo = new UserInfo(userId, "userId 对应的名称", Uri.parse("userId 对应的头像地址")) return userInfo;}},true); 如此设置完用户信息提供者之后,在获取到用户信息之后,于此同时调用 RongIM.getInstance().refreshUserInfoCache(userInfo); 将用户信息缓存起来,那么问题来了,若是用户信息批改了,该如何解决呢? 以下我将我应用的形式提供给大家,供大家参考: 我设置了一个自定义音讯 ,UserInfoChangeMessage,自定义音讯可参考融云文档;在某个用户更新个人信息之后,发送自定义音讯告诉与此用户相干的所有相关者。此音讯倡议有服务端发送;在其余用户收到此音讯之后,通过音讯携带的Userid ,来从新从服务获取最新的用户信息,而后在调用RongIM.getInstance().refreshUserInfoCache(userInfo); 将用户信息刷新缓存;通过以上三步,即可实现用户信息的更新。

March 15, 2021 · 1 min · jiezi

关于音视频:关于融云聊天室KV-值的正确使用

在应用融星散成即时通讯的过程中,依据产品业务逻辑,咱们应用了融云聊天室场景,因为咱们次要做的是直播聊天室的业务;在应用聊天室的过程中,理解到融云这边是有针对聊天室属性做解决的,这样的话,更加不便产品的某些性能点的实现,比如说 人数的动态变化等等; 现就我这边理解到的聊天室的KV 对大家做一个阐明,增进对KV 应用的理解; 首先,要获取聊天室的属性,咱们当然应该退出聊天室,退出聊天室的形式如下所示: RongIM.getInstance().joinChatRoom(roomId, 20, new RongIMClient.OperationCallback() { @Override public void onSuccess() { } @Override public void onError(RongIMClient.ErrorCode errorCode) { } }); 以上办法无需多言,调用即可退出聊天室,具体参数文档能够参考融云文档。 当然,要获取聊天室属性获取之前,必定要晓得如何设置聊天室属性的,以下形式次要展现客户端的设置形式: RongIMClient.getInstance().setChatRoomEntry(chatRoomId, key, value, sendNotification, isAutoDel, notificationExtra, new RongIMClient.OperationCallback() {/** 胜利回调*/@Overridepublic void onSuccess() { }/** 失败回调@param errorCode 错误码*/@Overridepublic void onError(RongIMClient.ErrorCode errorCode) { } }); 接下来就是获取的形式了,这块是我在集成过程中破费工夫比拟久的,在获取之前,须要先理解融云对于聊天室KV 的整体流程设置: 退出聊天室之后,通过设置的监听 setKVStatusListener 来获取到服务KV 的变动,而后在收到变动之后,在调用 getChatRoomEntry 来获取KV 值即可 。留神:前提条件是设置监听获取到KV 变动之后,才去获取,因为这个变动是服务收回的,也就是说这是一个告诉状态; 监听的设置形式: RongIMClient.getInstance().setKVStatusListener(new RongIMClient.KVStatusListener() {@Overridepublic void onChatRoomKVSync(String roomId) { } @Override public void onChatRoomKVUpdate(String roomId, Map<String, String> chatRoomKvMap) { } @Override public void onChatRoomKVRemove(String roomId, Map<String, String> chatRoomKvMap) { } }); ...

March 15, 2021 · 1 min · jiezi

关于音视频:融云聊天室属性-kv

近期又又又加需要了,领导想要聊天室中的所有人看到的点播视频的进度都是雷同的,由房主来操作进度条,其他人追随房主的进度条进行视频进度条的调整,以前的逻辑是大家看到的视频进度都是依据本人的操作来,最开始的技术上应用自定义音讯,然而起初后进入聊天室的成员无奈收到自定义音讯,束手无策几分钟后, 在官网找个电话:融云官网:https://www.rongcloud.cn/电话征询后,举荐应用聊天室属性,概念很生疏,但理解了个大略。 应用过程房主设置属性值,其余角色获取 kv 值依据 kv进行进度条的调整。 房主设置进度条属性RongIMClient.getInstance().setChatRoomEntry(chatRoomId, key, value, sendNotification, isAutoDel, notificationExtra, new RongIMClient.OperationCallback() { /** 胜利回调*/ @Override public void onSuccess() { } /** 失败回调@param errorCode 错误码*/ @Override public void onError(RongIMClient.ErrorCode errorCode) { }}); 2.其余端监听属性 RongIMClient.getInstance().setKVStatusListener(new RongIMClient.KVStatusListener() { /** 退出聊天室胜利后,SDK 默认从服务端同步 KV 列表,同步实现后触发* @param roomId 聊天室 Id*/ @Override public void onChatRoomKVSync(String roomId) { } /** 更新时全量返回 KV 属性,更新蕴含新增、批改* @param roomId       聊天室 Id@param chatRoomKvMap 发生变化的 KV*/ @Override public void onChatRoomKVUpdate(String roomId, Map<String, String> chatRoomKvMap) { } /** ...

March 12, 2021 · 1 min · jiezi