微信小程序> 微信小程序直播开发-微信小程序用什么平台开发-微信小程序开发用什么技术

微信小程序直播开发-微信小程序用什么平台开发-微信小程序开发用什么技术

浏览量:1925 时间: 来源:迟钝的焼年
微信小程序直播怎么开发,本篇教程带你了解小程序直播开发中的秘密。大家有没有发现,小程序直播的方式在我们身边的会议、客户服务、约会中应用得越来越多……看到这些,不少开发者就着急了:怎样才能开发出例如小程序直播、小程序在线语音客服、小程序视频会议等等服务?其实,这些玩得很6的小程序直播,都少不了它的支持——2017年下半年,微信6.5.21版本支持在线音视频功能。开发者可以通过两个音视频组件live-pusher和live-player实现实时地在线直播、视频通话、语音通话等功能。本期小程序课,微信开发哥将详细为大家介绍一下音视频组件在线直播和视频通话这两个应用场景。在线直播该怎么做?1、在线直播的应用场景有哪些?在游戏直播、远程授课、以及企业内部的培训分享等场景中,都可能会用到在线直播功能,直播的应用场景可以遍及各行各业。比如微信电竞是一款游戏直播产品,以小程序为产品呈现方式。比如在医疗行业,专家医师往往需要全国各地飞进行学术交流和培训,出差本身耽误了医生大量时间,在线远程授课能大大减少这里的时间耗用。小程序中的live-pusher和live-player两个组件,都有一个叫做live(live-pusher中对应mode属性为SD,HD,FHD)的模式,专门为在线直播而设计,通过小程序的音视频接口的live模式,可以实现上述应用场景。2、在线直播的内部原理是什么?主播端使用live-pusher,它在微信小程序的内部是一个推流引擎,它负责对手机摄像头和麦克风的数据进行采集和编码,并通过url参数指定的rtmp推流地址上传到云端。云端的作用类似信号放大器,它负责将来自主播端的一路音视频流数据进行放大,将数据实时并且无差异的负责并扩散到全国各地,从而解决主播和观众端之间距离太远(比如,跨地区和跨运营商)的问题。观众端使用live-player进行播放,它在小程序的内部是一个在线播放器,负责从云端实时拉取音视频数据并进行解码和渲染。由于云端的放大效应,每一个观众都能在离自己比较近的云服务器上拉取到实时且流畅的音视频流。3、我怎么用小程序实现在线直播?step1:开通一个云直播服务(比如腾讯云),或者自己搭建一个rtmp服务器(例如nginx-rtmp服务)。step2:生成推流url,推流地址一般以“rtmp://”打头,比如rtmp://8888.livepush.myqcloud.com/live/8888_test就是一个典型rtmp推流Url。step3:为你的小程序增加一个live-pusher标签,并将url参数指定为你在step2中生成的推流url。同时,live-pusher的mode参数可以指定为HD或者FHD,这是在线直播场景中比较推荐的画质。同时,你还可以通过live-pusher的beauty和whiteness等参数设定美颜和美白等级。step4:生成推流url和播放地址,推流一般都是rtmp://打头的url,而播放地址则有两种选择,分别是“rtmp://”开头的rtmp播放协议,“http://”打头和“.flv”结尾的的http-flv播放协议,推荐使用后者,因为这种播放地址各个云厂商都优化的比较好。step5:为你的小程序增加一个live-player标签,并将src参数指定为你在step4中生成的播放url。同时,live-player的mode参数请指定为live,orientation和object-fit属性可以用于调整画面布局,min-cache和max-cache则可以用于控制观众跟主播之间的延时大小,推荐的设置是min-cache2,max-cache5。关于在线直播,你会有这样的疑问1、时延太高是怎么回事?在线直播的延时跟播放协议和播放器参数有很大的关系,live-player的min-cache和max-cache用于控制播放器端的最小时延和最大时延。其中,这里所说的“最小”和“最大”是根据观众端当时的网络情况而定的,如果网络情况比较好,那么播放器的时延就会趋向于min-cache,而如果网络情况比较差,那么播放器的时延就会趋向于max-cache。另外,rtmp协议和http-flv协议的播放地址延时一般比较低,而hls(m3u8)协议的延时则相对较高。2、主播网络不好怎么办?在一场直播过程中,如果观众端的网络不好,那么观看体验仅仅影响到当前观众;如果主播的网络不好,那么所有观众的观看体验都会很糟糕。因此主播的上行网络质量很重要,如果主播的上行网络质量不理想,比如时好时坏,或者上行小水管,不足以支持基本的直播需求,有两种办法可以解决问题:一种办法是设置live-pusher的min-bitrate参数,比如400kbps,这样一来,当主播网络不给力的时候,live-pusher就会给主播的编码器发送降低画质的命令,通过降低编码器吐出的数据量来给主播的网络减负。但这种办法产生的副作用也非常明显,就是主播的画质会变差。另一种方法则是借助live-pusher的NET_BUSY通知进行UI上的告警提示,live-pusher在主播上行网速不给力时会通过onPushEvent通知抛出PUSH_WARNING_NET_BUSY(1101)事件,这个时候你可以提示主播通过靠近路由器或者切换4G的方法来改善当前的网络质量。3、HLS(m3u8)协议为什么播放不了?微信小程序在最早期的版本中就集成了video标签,该标签即可播放HLS(m3u8)协议的播放地址,但是此种播放协议的时延一般都在20秒以上,所以如果对时延要求较高,则推荐使用live-player标签播放http-flv协议的直播地址。视频通话,你也能开发1、小程序+视频通话有什么优势?我们可以发现目前保险行业会通过现场定损的方式处理车险理赔,这种方式需要派定损员驱车前往事发地点进行损伤判定,每次的出车成本非常高。如果要采用远程电话解决,保险公司无法简单通过语音沟通确认损伤程度,而且照片采集很难规避定车骗保的可能,所以**实时的视频通话**可以解决这种问题。小程序中live-pusher和live-player两个组件,都有一个叫做RTC的模式,通过这种模式,可以在小程序实现实时视频通话。2、视频通话的内部原理是什么?live-pusher和live-player两个组件的RTC模式,主要是实现端到端能够以很低的时延传输音视频数据。这样一来,视频通话的双方A和B就可以各自拉通一路方向相反的音视频链路,从而实现A和B之间的双向低延时的音视频数据传输。与此同时,RTC模式还会开启内置的AEC(回声抑制),避免通话的双方会因为本地麦克风对播放器的声音进行二次采集而引起的回声问题。3、我怎么用小程序实现视频通话?step1:开通一个云直播服务(比如腾讯云),或者自己搭建一个rtmp服务器(例如nginx-rtmp服务)。step2:生成两对rtmp推拉流url:一对是用于A端推流的push_url_a和用于播放A端视频的play_url_a;另一对是用于B端推流的push_url_b和用于播放B端视频的play_url_b;step3:A端添加一个live-pusher标签,指定mode为RTC,并将url输定设定为push_url_a。step4:A端添加一个live-player标签,指定mode为RTC,并将src输定设定为play_url_b。step5:B端添加一个live-pusher标签,指定mode为RTC,并将url输定设定为push_url_b。step6:B端添加一个live-player标签,指定mode为RTC,并将src输定设定为play_url_a。关于视频通话,你会有这样的疑问1、通话时延太高了怎么办?小程序的RTC模式解决了双向或者多人实时音视频通话在终端所需要的各项技术组件,但是通话线路本身可能也会引入很高的延时,所以要确保视频通话的A和B双方所使用的rtmp线路要有很低的时延。如果是自己搭建rtmp服务器(例如nginx-rtmp服务),请检查nginx-rtmp的服务端参数设置,确保不要在服务器端引入太多音视频数据缓存。如果是使用腾讯云的超低延时线路,那么要注意给RTC模式下的live-player传递带防盗链签名的播放url。对比项目示例时延普通直播URLrtmp://3891.liveplay.myqcloud.com/live/3891_test_clock_for_rtmpacc2s超低延时URLrtmp://3891.liveplay.myqcloud.com/live/3891_test_clock_for_rtmpacc?bizidbizidtxTime5FD4431CtxSerect20e6d865f462dff61ada209d53c71cf9500ms2、感觉画面很卡应该如何处理?小程序的RTC模式主要用于视频通话,由于这类场景以交流为重,所以小程序会有限保证声音的流畅,相应的,视频数据的发送会被放在第二优先级上。因此,如果网络有波动,小程序会舍弃尚未发送出去的视频数据,优先保障音频数据的发送。所以如果在RTC模式下,建议不要给live-pusher设置太高的画质,也就是不要将min-bitrate和max-bitrate设置的太大,一般而言,推荐min-bitrate设置为300kbps,max-bitrate设置为800kbps,即可满足常规视频通话的需求。

版权声明

即速应用倡导尊重与保护知识产权。如发现本站文章存在版权问题,烦请提供版权疑问、身份证明、版权证明、联系方式等发邮件至197452366@qq.com ,我们将及时处理。本站文章仅作分享交流用途,作者观点不等同于即速应用观点。用户与作者的任何交易与本站无关,请知悉。

  • 头条
  • 搜狐
  • 微博
  • 百家
  • 一点资讯
  • 知乎