APP下载

刘连响:为什么看好小程序音视频在教育行业的应用?

消息来源:baojiabao.com 作者: 发布时间:2024-03-29

报价宝综合消息刘连响:为什么看好小程序音视频在教育行业的应用?

作者简介:刘连响,一起玩耍科技创始人。2013年起开始研究WebRTC, 对音视频处理、 直播、实时音视频相关技术非常感兴趣,具有多个实时音视频产品研发经验。目前关注实时音视频在在线教育,医疗行业的应用。

今天为大家带来的分享是:小程序实时音视频在互动教育场景下的应用。我个人一直在做基础方面的研究,接触音视频也比较早,2013年的时候就开始做包括直播在内的相关产品,有多个音视频研究的相关经验。目前我们关注教育、医疗方向的音视频,以及有关这方面的应用。

下面是我与客户沟通中列出的一些问题,也就是做一个线上教育实时互动的产品会面临的问题:

没有摄像头。比如一个PC机,有些是没有摄像头。如果想要进行视频教育,需要额外买一个摄像头。这就是用户端遇到的问题。

背景比较混乱。一个孩子在固定的电脑前,因为身后的背景比较混乱,可能会不太愿意打开视频。固定电脑没有办法很好地移动,这也是一个问题。


终端设备多样。大家使用的是iPad、手机以及各种各样的电脑,这是多样设备适配的问题。

设备调试。设备的调试跟上一个问题相辅相成,我们发现一些教育客户,要花很多能力给它的C端用户做培训,手机上没有声音,声音变小了,或者类似各种各样的问题,他要花很多人力进行远程电话支持,你要怎么操作。

教务系统多种。这是面对SaaS客户遇到的问题,没有办法接入到排课系统。

网络延迟、视频卡顿。目前为止没有一个特别完美的解决方法,只能说行业在不断进行优化,提升体验。

以上是我列出的问题。有人提到音视频延迟这部分的问题,音频很流畅,但是视频不行,这个技术问题可以归为视频卡顿中。

小程序音视频是怎么解决这个问题的呢?先说一下方案介绍。

零基础快速对接。这个比较好理解。小程序提供音视频组件JS API,无须具备音视频基础知识就可以进行应用。

卓越的音视频品质。腾讯已经做了十几年,从QQ时代就有视频通话,质量是端到端、400毫秒以下的延迟、800毫秒的网络抖动,30%丢包。

跨平台互通。小程序、安卓、IOS、Web端,都可以用它的SDK去解决这个问题。


我们为什么会看好小程序音视频在教育行业的应用呢?

首先是统一的平台”微信OS”,主要有以下几点:

第一,统一的账户系统。一个APP需要用户去注册登录,而微信有用户头像,有完备的用户信息, 这是微信已经做好的。

第二,标准的界面。小程序的界面很标准,只要记住两个东西就可以,一个是上,一个是下。这两个有相关的界面,只要记住有上有下就可以了。

第三,极简的API。

第四,软硬件遍解码底层适配。如果你做音视频相关的解决方案,尤其是安卓端,iOS还好一些。安卓端因为每个平台硬件的底层不太一样,需要进行适配,比如高通的、三星的、英特尔的芯片,可能每家每个型号的芯片、表现都不一样,这时就需要花很长的时间做适配。我们做这个东西就很痛苦,没有办法通过简单的代码来解决。

在小程序里就不需要担心了,腾讯基于多种机型的适配,已经做得比较完善了。

第五,降噪回升消除。为什么有回声?背景为什么那么噪杂?这是比较难解决的问题,行业里真正做得好的只有很少一部分。

第六,统一的操作路径。小程序都是一样的规范、一样的操作,这些都是非常统一的。


以上是统一平台的部分,下面介绍非常低廉的群传播、打开成本。这是我们的界面,相当于创建一个课堂之后,小程序为你提供了分享的界面,可以做分享的动作。它的分享成本非常低廉。我们假设在原生的APP场景分享了一个链接之后,别人需要下载一个APP进行注册,再回到那个房间、教室,小程序可以极大地简化这个流程。

小程序生态完备。在教育环境,我们有四个环节,教、练、测、管。大家看到录播产品、直播产品,经常在朋友圈转发的课程,这是教的环节。练的环节,我们看到的一些相关产品,比如打卡、题库、作业等,各位多多少少也接触过。测,就是线上考试、比赛、PK的部分。管,就是基于微信群,或者一些督学和家长沟通的工具。在微信小程序环节里面,每一个环节里面都有相应的产品。你再设计解决方案的时候,完全不需要做一个教育产品,还需要做其他的吗?不需要了,你可以在这个生态里只做你擅长的教学内容,其他部分可以和整个生态其他的工具串联起来,你可以有相对统一的用户唯一标识,这是一个非常好的生态,可以帮助你的业务更好地发展。以上是我总结出来的三个点,统一的平台、低廉的传播成本和完备的生态。

那么我们是怎么做的呢?我们刚开始就做了一些小的尝试,内部已经有了产品,下面主要为大家讲一下这个过程中的几点。

首先是基础框架,腾讯官网推出了一个官方的小程序框架,我们选了vuejS和wepy这两个技术。如果你会这两个,一天就可以进行小程序开发了。另外一个是socketio。市面上有些人做了一些第三方的实现,但是我们发现它的bug很多,因为它毕竟不是为小程序而生的,只能移到小程序中使用。typescript的前端和后端都可以用同样的语言来开发,大部分的数据都直接存在redis里面,像一些实时的场景,比如房间管理、操作历史等一系列相关的东西都可以用Reids。我们一开始的时候也有被坑到的点,音视频的部分需要单独开放许可权,它开放了直播、教育、医疗和金融这四个分类。如果不开放许可权,在调用相关界面的时候就会报错,这里还是需要设置一下。

下面介绍一下产品设计的时候需要特别注意的部分,因为音视频是一个原生组件,它的层级比其他都要高,这时不能做复杂的交互。简单的滑动还可以做,其他的复杂交互不太好做,比如动画、放大、缩小,很容易造成闪退。最好布局和UI相对简单固定的,我们一开始的交互设计比较复杂,最终改了两个版本,比较简单一些。但现在还有这样的问题存在,需要用更长的时间进行优化。音频比视频更简单一些,因为它的资源消耗比视频小很多,音频的房间几十个人都没有问题,主要是看大家的需求。两三个人进行互动,其他人观看,是这样的一个场景。

教育跟白板是少不了的,包括视频白板。我们做了ppt、doc、pdf格式,现在的版本做得相对简单,相当于把PPT、文档和PDF转成一张张图片进行同步,包括回放的录制。回放后,需要鼠标的指示或三角形、画线操作,在进行广播的时候可以同步在学生端。

文档格式转换,因为会涉及到一些变形的问题,我们摸索出来比较好的方式就是用OpenOffice headless mode。它没有UI,可以拿来操作,通过OpenOffice headless mode的界面进行转换。经过测试下发现它的还原度比较好,不会有太多变形。腾讯云也有文档转换的服务,因为我们已经做了这个部分,也希望对这个系统更可控,所以就自己做了一套转换的服务。


操作历史记录,比如老师翻到下一页、老师画了一个三角形,这些都需要记录下来。提供给你一个时间戳,在回放的时候,根据时间轴就可以。

多人授权白板,相当于老师布置了一个任务让学生进行操作,可以将白板授权给学生,学生来操作白板,老师也可以把许可权收回。

动画、音频、视频的支持,目前来看没有很好的方案。例如一些幼教的产品,3岁到6岁这种,它的可见非常活泼、非常丰富,各种动画、视频比较多。单纯的图片转换不太能满足这种需求,这时就需要一些机构进行动画相应的转化。目前,小程序的底层技术还无法很好地支撑这些东西,我们可以在PC端进行这部分。

小程序暂时没有办法支持PDF,这不是小程序的问题,而是操作系统的问题,上传的时候只能选图片和视频。现在iOS已经支持了,可以选择其他文件。而安卓还没有一个统一的结构,小程序目前还不能支持,只能上传一张张图片。

云端录制可以方便学生之后再进行学习,腾讯在小程序音视频上提供了云端的录制,其实就是标准的rtmp流。这部分是额外收费的,如果需要录制的服务可以进行开通。

关于截图鉴黄,教育场景有必要做这些吗?还是非常有必要的。在中国这种大的环境下,多注意都不过分,以防万一,这部分真的非常有必要。

关于云端混流,比如说一个房间里面有五路音视频,你需要把这些流混起来。还有一些其他更特殊的场景,需要将PPT和老师的操作都混起来,这是有一些麻烦的。目前腾讯云的方案提供了视频的混流,可以将多个视频混流,但还没有提到PPT和音视频混流的方案。这部分我们自己有实现一套方案,你可以把音视频录制下来再进行合成。因为我们之前做过类似方案,有一些相应的技术积累,我们尽量在做服务的时候,能可以自己把控的就尽量自己把控。

关于云存储,在录制下来之后存放在腾讯云上面就可以了。

关于合成ffmpeg、moviepy,如果遇到一些合成效果就可以来研究一下,常见的视频效果都可以通过几行命令行来搞定。


关于浏览器合流、screen recorder,大家想像一个场景,在整个教育过程中需要回放合流的时候,假如一个房间五个人,在服务端合流很难完美地浮现学生当时看到的场景,因为回放和学生当时看到的不是完全之一致的。而且像PPT这种操作,没有办法完美合进去。这时候我们有一些技巧,浏览器的合流可以把几个视频合成一个流。甚至把白板、视频、音频都合成一个视频录制下来上传到服务端。它可以将当前窗口完美录制下来,比合流的效果更好一些。这个方案可以考虑,但是有限的浏览器支持,作为一个对服务端混流的补充。

我们应该怎么做呢?

WebRTC大家都了解,可以很快地做一个demo。小程序为了节省资源,用的不是RTC的技术,很多市面上的产品已经有那么多平台支持了,这要怎么办呢?腾讯确实也提供了这样的方案,像WebRTC。小程序的音视频就是rtmp,它在传输时基于UDP的协议,只需要将这两个东西打通就可以。腾讯在服务端已经在做将这两种动态打通,我们正常去做音频转码就可以了。腾讯云团队将相关的操作都已经封装成一个比较好的组件,比如RTC多人动画的组件。

WebRTC这部分的能力可以使PC端和小程序进行互通,打包成一个组件提供给大家。同时它也提供相应的服务端的代码,有java版本。它提供的服务可以某种程度满足你的需求,毕竟做得相对集成一些,我们相当于在这个基础之上,自己封装了一套,因为还有很多定制化的需求在。比较好的是你可以快速搭建一个demo,很快地跑起来看到是什么效果。如果真正做深的话,还要基于自己的理解去封装一套东西。

我们说了一些好的方面,接下来再说一下存在的问题:

视频原生组件,不能做太多复杂的交互。视频的部分,它的原生组件,在视频上没有办法做复杂的交互。比如视频之上不能覆盖东西,或者只能覆盖一些比较简单的东西,基于视频的动画也不可以。

品类限制。现在只有四个品类,限制比较多。教育品类已经开放,大家可以使用,也希望可以开放更多的品类,做出更多的场景。

不支持pad。在相对大屏上是不可以的,只能用PC端的产品来进行替代。

不支持模拟器调试。正常开发一个场景,在写完代码后,用这个手机扫一下,另外一个手机再扫一下,调试过程相对痛苦,希望可以支持中远程去调试。


上传文件的限制。这是操作系统的限制,不是小程序的限制。我们希望在操作系统进化的时候,小程序也将相应的能力提升上去。


Q/A


Q:我们发现市场有个特定的应用,刚好跟视频结合比较完美,数量大概有1亿以上。目前了解到有没有支持到这个量级?这个应用已经到了1亿的浏览量上,不知道您现在做的应用,有没有支持大并发?

A:视频能支持这种量级很难,比如斗鱼这种高并发级别宣称有几百万,其实也到不了,可能几十万已经差不多了。主要的压力在于视频,比如现在有的机构一天的课堂数有几万节,这已经非常多了。像你说的1亿可能是应用人数,这不一定就代表了高并发。

Q:您是公司的创始人,我不是做互联网行业的,对这部分不太了解。作为一个外行人想问两个关于产品的问题。第一,我们基于腾讯云小程序所做的开发,随着用户量越来越庞大,对于腾讯云小程序的耦合性越来越紧。紧耦合性将带来一个问题,对腾讯的依赖会越来越深。现在量没有上去时对我们不收费。量级上去就会收费很多。而且,腾讯有自己的公开课或腾讯课堂,我们做的产品对腾讯的市场有了冲击,我们还依赖于它,这种问题应该如何处理?

A:我说一下自己的看法,每个阶段你都有应该考虑的问题。首先更多的还是把产品打磨好,第二个阶段其实你已经有足够的能力摆脱这方面的限制。一个很现实的情况就是,如果你到达一定量级后,很多公司到了C轮、D轮级别,才开始大量去铺自己的基础IT设施。我觉得如果到了两个量级,再考虑这个问题比较OK。我跟腾讯云交流比较多,他们选择一种合作模式,这点从过去几年腾讯一些具体例子可以看到,我认为腾讯还是相对开放。你的问题可能会作为忧虑的一部分,但更多还是把自己的产品做好,让更多的人使用。

Q:现在大家基于小程序做了很多程序,做了自己的APP。平台是没有技术壁垒的,一个没有技术壁垒的产品,是很容易被模仿的。不知道您的投资人是否咨询过关于技术这部分的问题,如果没有技术壁垒,如何在同类产品突出自己的产品亮点,或者凭什么吸引我们?比如教育行业的一些名师就是师资资源上的亮点,但从程序本身,有没有可以打造亮点的地方?

A:技术和产品在这个环节中的应用我想要说明一下,虽然我是技术出身,很重视技术,但是不得不承认一点,在某些行业里技术和产品只是第一步,是重要的第一步。每个公司、每个业务一定是一个整体。你不能说,我只有这一部分强。教育行业是很重服务的,它有很多老师。在这种场景下,它确实很重要,同时还有上层的业务打造。考虑这个问题的时候,还是要想清楚自己的优势,自己能做什么?有什么样的资源?如果你有技术,确实可以省去很多的时间和精力。



回声消除AEC包含:   延时估计对齐+线性自适应滤波器+NLP(双讲检测、处理)+舒适噪声CNG
一、speex aec
1、没有NLP
2、只考虑实时DSP系统,即是没有延时对齐等
3、自适应滤波(MDF)使用双滤波器结构,自适应滤波器因子自动更新

二、webrtc aec
1、双讲检测没有,双讲时远端的声音会消没了
2、PBFDAF,固定自适应因子 0.6
3、抑制是使用相关性技术,近端误差,近端远端,由低频段相关性参数求出gain值
对于aec,webrtc主要依赖NLP,speex主要是自适应滤波器(双滤波器)
三、实际效果对比:如果样本非线性不严重,两者的效果都不错;对于非线性speex效果就很差了,webrtc的效果好;双讲时,webrtc出来的音质就很差,有吃音现象。至于webrtc的aecm音质差,单讲会有吱吱声。
四、优化点:对webrtc的aec加入双讲检测,双讲处理。
五、由于mic与扬声器对非线性影响比较大,自已硬件产品可以考虑使用比较好的mci与扬声器,极大减少nlp的抑制程度。对于dsp而言,实时性比较好,延时估计对齐可以不要。最后推荐使用webrtc aec。

2018-07-04 08:31:00

相关文章