SFU_MCU

SFU_MCU

8
评论

【源码下载】一款使用环信实现的开源灵魂社交APP(含服务器) 猿匹配 开源

beyond 发表了文章 • 13077 次浏览 • 2019-07-01 10:48 • 来自相关话题

#前言
近期,环信热心开发者-穿裤衩闯天下使用环信IM开发了一款实时聊天应用,包含简单的服务器端,现在正式开源给小伙伴们。感兴趣的同学可以一起搞一下哦,详细介绍请往下看。






  上代码
服务器:VMServer
客户端:VMMatch
 
 #VMMatch
猿匹配 —— 国内首个程序猿非严肃婚恋交友应用,让我们一言不合就来场匹配吧
 
#介绍#
首先说下中文名:为什么叫这个名字呢,因为这是一个程序猿(媛)之间匹配交流的应用啊其实这是一个使用环信 IM 开发的一款开源聊天项目,涵盖了时下流行的一些聊天元素,同时已将 IM 功能封装为单独库,可以直接引用,方便使用
项目还处在初期阶段,还有许多功能需要实现,有兴趣的可以一起来
项目资源均来自于互联网,如果有侵权请联系我
 
 #下载体验
猿匹配 小米商店 审核中
猿匹配 Google Play
 
  #项目截图

























  
 #开发环境
项目基本属于在最新的Android开发环境下开发,使用Java8的一些新特性,比如Lambda表达式,
然后项目已经适配Android6.x以上的动态权限适配,以及7.x的文件选择,和8.x的通知提醒等;
· Mac OS 10.14.4
· Android Studio 3.3.2
  #项目模块儿
本项目包含两部分:
一部分是项目主模块app,这部分主要包含了项目的业务逻辑,比如匹配、信息修改、设置等
另一部分是封装成library的vmim,这是为了方便大家引用到自己的项目中做的一步封装,不用再去复杂的复制代码和资源等,
只需要将vmim以module导入到自己的项目中就行了,具体使用方式参见项目app模块儿;
 
  #功能与 TODO
IM部分功能
· [x] 链接监听
· [x] 登录注册
· [x] 会话功能
      。[x] 置顶
      。[x] 标为未读
      。[x] 删除与清空
      。[x] 草稿功能
· [x] 消息功能
      。[x] 下拉加载更多
      。[x] 消息复制(仅文字类消息)
      。[x] 消息删除
      。[x] 文本+Emoji消息收发
      。[x] 大表情消息收发
      。[x] 图片消息
        ~[x] 查看大图
        ~[ ] 保存图片
      。[x] 语音消息
        ~[x] 语音录制
        ~[x] 语音播放(可暂停,波形待优化)
        ~[x] 听筒和扬声器播放切换
      。[x] 语音实时通话功能
      。[x] 视频实时通话功能
      。[x] 通话过程中的娱乐消息收发
        ~[x] 骰子
        ~[x] 石头剪刀布
        ~[x] 大表情
      。[x] 昵称头像处理(通过回调实现)
App部分功能
· [x] 登录注册(包括业务逻辑和 IM 逻辑)
· [x] 匹配
      。[x] 提交匹配信息
      。[x] 拉取匹配信息
· [x] 聊天(这里直接加载 IM 模块儿)
· [x] 我的
      。[x] 个人信息展示
      。[x] 上传头像
      。[x] 设置昵称
      。[x] 设置签名
· [x] 设置
      。[x] 个人信息设置
      。[x] 通知提醒
      。[x] 聊天
      。[ ] 隐私(随业务部分一起完善)
      。[ ] 通用(随业务部分一起完善)
      。[ ] 帮助反馈(随业务部分一起完善)
      。[x] 关于
      。[x] 退出
· [ ] 社区
      。[ ] 发布
      。[ ] 评论
      。[ ] 收藏
      。[ ] 关注
发布功能
· [x] 多渠道打包
· [x] 签名配置
· [x] 开发与线上环境配置
· [x] 敏感信息保护
 
  #配置运行
1.首先复制config.default.gradle到config.gradle
2.配置下config.gradle环信appkey以及bugly统计Id
3.正式打包需要配置下签名信息,同时将签名文件放置在项目根目录
 
  #参与贡献
如果你有什么好的想法,或者好的实现,可以通过下边的步骤参与进来,让我们一起把这个项目做得更好,欢迎参与
1.Fork本仓库
2.新建feature_xxx分支 (单独创建一个实现你自己想法的分支)
3.提交代码
4.新建Pull Request
5.等待我们的Review & Merge
 
 #关联项目
服务器端由nodejs实现,地址见这里 VMServer
 
  #VMServer
是为Android开源项目VMMatch项目(中文名猿匹配)实现的服务端
 
  #简介
这个项目包含两部分
· 根目录:服务逻辑及API接口实现
· client目录:前端界面,和服务器端代码端放置在同一仓库下(暂未实现)
 
 #使用
简单介绍下运行环境及部署方法
1.安装nodejs开发时使用的是v10.16.0版本
2.需要安装mongodb并启动,开发使用版本4.0.10
3.下载项目到服务器,可以下载压缩包,或者用git clone命令
4.复制config_default.js到config.js,可根据自己需要修改配置文件
5.安装依赖npm install
6.全局安装pm2npm install pm2 -g 
7.运行 vmshell.sh
 




扫码备注【开源项目】邀你加入环信开源社群
 
转载自https://blog.melove.net/develop-open-source-im-match-and-server/ 
  查看全部
#前言
近期,环信热心开发者-穿裤衩闯天下使用环信IM开发了一款实时聊天应用,包含简单的服务器端,现在正式开源给小伙伴们。感兴趣的同学可以一起搞一下哦,详细介绍请往下看。

猿匹配_logo_副本.png


  上代码
服务器:VMServer
客户端:VMMatch
 
 #VMMatch
猿匹配 —— 国内首个程序猿非严肃婚恋交友应用,让我们一言不合就来场匹配吧
 
#介绍#
首先说下中文名:为什么叫这个名字呢,因为这是一个程序猿(媛)之间匹配交流的应用啊其实这是一个使用环信 IM 开发的一款开源聊天项目,涵盖了时下流行的一些聊天元素,同时已将 IM 功能封装为单独库,可以直接引用,方便使用
项目还处在初期阶段,还有许多功能需要实现,有兴趣的可以一起来
项目资源均来自于互联网,如果有侵权请联系我
 
 #下载体验
猿匹配 小米商店 审核中
猿匹配 Google Play
 
  #项目截图

1.png

2.png

3.png

4.png

5.png

6.png

  
 #开发环境
项目基本属于在最新的Android开发环境下开发,使用Java8的一些新特性,比如Lambda表达式,
然后项目已经适配Android6.x以上的动态权限适配,以及7.x的文件选择,和8.x的通知提醒等;
· Mac OS 10.14.4
· Android Studio 3.3.2
  #项目模块儿
本项目包含两部分:
一部分是项目主模块app,这部分主要包含了项目的业务逻辑,比如匹配、信息修改、设置等
另一部分是封装成library的vmim,这是为了方便大家引用到自己的项目中做的一步封装,不用再去复杂的复制代码和资源等,
只需要将vmim以module导入到自己的项目中就行了,具体使用方式参见项目app模块儿;
 
  #功能与 TODO
IM部分功能
· [x] 链接监听
· [x] 登录注册
· [x] 会话功能
      。[x] 置顶
      。[x] 标为未读
      。[x] 删除与清空
      。[x] 草稿功能
· [x] 消息功能
      。[x] 下拉加载更多
      。[x] 消息复制(仅文字类消息)
      。[x] 消息删除
      。[x] 文本+Emoji消息收发
      。[x] 大表情消息收发
      。[x] 图片消息
        ~[x] 查看大图
        ~[ ] 保存图片
      。[x] 语音消息
        ~[x] 语音录制
        ~[x] 语音播放(可暂停,波形待优化)
        ~[x] 听筒和扬声器播放切换
      。[x] 语音实时通话功能
      。[x] 视频实时通话功能
      。[x] 通话过程中的娱乐消息收发
        ~[x] 骰子
        ~[x] 石头剪刀布
        ~[x] 大表情
      。[x] 昵称头像处理(通过回调实现)
App部分功能
· [x] 登录注册(包括业务逻辑和 IM 逻辑)
· [x] 匹配
      。[x] 提交匹配信息
      。[x] 拉取匹配信息
· [x] 聊天(这里直接加载 IM 模块儿)
· [x] 我的
      。[x] 个人信息展示
      。[x] 上传头像
      。[x] 设置昵称
      。[x] 设置签名
· [x] 设置
      。[x] 个人信息设置
      。[x] 通知提醒
      。[x] 聊天
      。[ ] 隐私(随业务部分一起完善)
      。[ ] 通用(随业务部分一起完善)
      。[ ] 帮助反馈(随业务部分一起完善)
      。[x] 关于
      。[x] 退出
· [ ] 社区
      。[ ] 发布
      。[ ] 评论
      。[ ] 收藏
      。[ ] 关注
发布功能
· [x] 多渠道打包
· [x] 签名配置
· [x] 开发与线上环境配置
· [x] 敏感信息保护
 
  #配置运行
1.首先复制config.default.gradle到config.gradle
2.配置下config.gradle环信appkey以及bugly统计Id
3.正式打包需要配置下签名信息,同时将签名文件放置在项目根目录
 
  #参与贡献
如果你有什么好的想法,或者好的实现,可以通过下边的步骤参与进来,让我们一起把这个项目做得更好,欢迎参与
1.Fork本仓库
2.新建feature_xxx分支 (单独创建一个实现你自己想法的分支)
3.提交代码
4.新建Pull Request
5.等待我们的Review & Merge
 
 #关联项目
服务器端由nodejs实现,地址见这里 VMServer
 
  #VMServer
是为Android开源项目VMMatch项目(中文名猿匹配)实现的服务端
 
  #简介
这个项目包含两部分
· 根目录:服务逻辑及API接口实现
· client目录:前端界面,和服务器端代码端放置在同一仓库下(暂未实现)
 
 #使用
简单介绍下运行环境及部署方法
1.安装nodejs开发时使用的是v10.16.0版本
2.需要安装mongodb并启动,开发使用版本4.0.10
3.下载项目到服务器,可以下载压缩包,或者用git clone命令
4.复制config_default.js到config.js,可根据自己需要修改配置文件
5.安装依赖
npm install

6.全局安装pm2
npm install pm2 -g
 
7.运行 vmshell.sh
 
环信冬冬_副本.jpg

扫码备注【开源项目】邀你加入环信开源社群
 
转载自https://blog.melove.net/develop-open-source-im-match-and-server/ 
 
4
评论

在微信小程序里实现聊天室 聊天室 小程序

Tolazy 发表了文章 • 40640 次浏览 • 2019-04-19 17:49 • 来自相关话题

第一次搞小程序,老板让我实现一个聊天室功能,压力山大啊。
花了几天时间研究比较了一下方案,最后基于环信的小程序SDK 开发了一个聊天室。
 
准备工作
下载环信 小程序demo+sdkgit clone https://github.com/easemob/webim-weixin-xcx创建一个文件夹,将 demo 中的文件 comps、images、sdk、utils 拷贝到新的文件,文件目录说明



集成
登录环信没什么可说的,这里选择的是使用 username/password 登录,和demo中的一样,文件没有进行任何更改


在app.js 中注册的 WebIM.conn.listen, 然后在 登陆成功的回调 onOpened 设置的跳转页面,并将登陆的 username 赋给 myName,传到新的页面中使用


修改 roomlist.js 获取聊天室列表,是分页获取的,这里先偷个懒,获取了第一页 20 个聊天室


然后将listChatrooms() 分别在onLoad、onShow 内,更改下,将原有的 listGroups() 替换掉然后在roomlist.wxml 修改对应的 变量绑定名称





demo中的group.js 中,获取到的是当前登陆账号已加入的群组,咱们做的是聊天室功能,所以需要有一个加入的操作,找roomlist.js 中找到 into_room: function (event),然后填写加入聊天室的方法, 我是直接在当前这个里面加的跳转到聊天页面,并将当前登陆的IDmyName,聊天室IDgroupID,聊天室名称your 传给新页面


Ex:监听是否加入聊天室成功的回调是在 onPresence 中,type:memberJoinChatRoomSuccess,正常是监听这个回调跳转页面,有点麻烦就直接这样吧到会话页面后,需要修改一下对应的消息格式,在comps/chat/suit 目录下,将里面的文件对应的 js 文件根据文档给聊天室发送消息 格式进行修改,聊天室消息和群组消息不同,所以我目前是直接将getSendToParam()、isGroupChat() 注释,改成下面这样,demo 中下面还有代码的,这里就用 …… 代替了





就这样了,简单集成聊天室功能,demo中的UI 是开源的,可以根据自己的需求更改~下面是具体实现过程。代码也放在github 上了,有需要的兄弟自取。demo下载地址:https://github.com/lizgDonkey/room-xcx 查看全部
第一次搞小程序,老板让我实现一个聊天室功能,压力山大啊。
花了几天时间研究比较了一下方案,最后基于环信的小程序SDK 开发了一个聊天室。
 
准备工作
  1. 下载环信 小程序demo+sdk
    git clone https://github.com/easemob/webim-weixin-xcx
  2. 创建一个文件夹,将 demo 中的文件 comps、images、sdk、utils 拷贝到新的文件,文件目录说明
    ml.png

集成
  1. 登录环信没什么可说的,这里选择的是使用 username/password 登录,和demo中的一样,文件没有进行任何更改
    login.png
  2. 在app.js 中注册的 WebIM.conn.listen, 然后在 登陆成功的回调 onOpened 设置的跳转页面,并将登陆的 username 赋给 myName,传到新的页面中使用
    tz.png
  3. 修改 roomlist.js 获取聊天室列表,是分页获取的,这里先偷个懒,获取了第一页 20 个聊天室
    getroom.png
    然后将listChatrooms() 分别在onLoad、onShow 内,更改下,将原有的 listGroups() 替换掉
  4. 然后在roomlist.wxml 修改对应的 变量绑定名称
    listui.png
    list.png
  5. demo中的group.js 中,获取到的是当前登陆账号已加入的群组,咱们做的是聊天室功能,所以需要有一个加入的操作,找roomlist.js 中找到 into_room: function (event),然后填写加入聊天室的方法, 我是直接在当前这个里面加的跳转到聊天页面,并将当前登陆的IDmyName,聊天室IDgroupID,聊天室名称your 传给新页面
    joinrom.png
    Ex:监听是否加入聊天室成功的回调是在 onPresence 中,type:memberJoinChatRoomSuccess,正常是监听这个回调跳转页面,有点麻烦就直接这样吧
  6. 到会话页面后,需要修改一下对应的消息格式,在comps/chat/suit 目录下,将里面的文件对应的 js 文件根据文档给聊天室发送消息 格式进行修改,聊天室消息和群组消息不同,所以我目前是直接将getSendToParam()、isGroupChat() 注释,改成下面这样,demo 中下面还有代码的,这里就用 …… 代替了
    send.png
    chat.png
    就这样了,简单集成聊天室功能,demo中的UI 是开源的,可以根据自己的需求更改~下面是具体实现过程。代码也放在github 上了,有需要的兄弟自取。demo下载地址:https://github.com/lizgDonkey/room-xcx

4
评论

【开源项目】全国首个开源直播小程序源码

beyond 发表了文章 • 182789 次浏览 • 2018-07-20 17:30 • 来自相关话题

今天你看直播了吗?拥有10亿微信生态用户的小程序已经成为了继移动互联后的又一个现象级风口,随着微信小程序对外开放实时音视频录制及播放等更多连接能力,小程序与直播强强联合,在各行各业找到了非常多的玩法,小程序直播相比微信直播和APP直播更加简洁、流畅、低延时、多入口等众多优势迅速向商业直播领域及泛娱乐直播领域蔓延。从小游戏、内容付费、工具、大数据、社交电商创业者到传统品牌商们,都在努力搭上小程序直播这辆快车,以免错过微信生态里新的流量洼地。
 





作为一名环信生态圈资深开发者,本着对技术的热衷,对环信的眷恋和对党的忠诚,基于环信即时通讯云写了“直播购物小程序”,目前项目源码已全部免费开放,希望对有需求的企业和开发者提供一个思路和参考。
直播购物小程序源码github地址:https://github.com/YuTongNetworkTechnology/wechat_live/tree/master 
git打不开可直接点下面链接下载


小程序直播demo_2018-06-21.zip







直播购物小程序运行预览图 
 
小程序体验指南(仅需两步):
 
1、下载微信小程序开发工具,下载地址:https://developers.weixin.qq.c ... .html 
 




2、导入源码:将附件的源码解压直接导入 







环信小程序直播技术文档
一、 使用的技术
1、 环信IM直播室。
2、 微信小程序实时音视频播放组件live-player。
3、 推流软件(obs、易推流)等推流。
4、 视频流服务器(UCLOUD、七牛、腾讯)等视频流服务器。
二、 系统使用流程。
1、 视频推流软件将视频流推到流服务器。
2、 打开视频直播demo小程序注册环信账号。
3、 进入软件直播室进行测试。
三、 技术流程及使用的SDk
1、 注册环信账号
打开https://www.easemob.com/ 环信官网,点击右上角注册按钮,选择[注册即时通讯云]




填写对相关信息进行注册





注册成功后进行登录




注:新注册用户需进行账号的认证。
2、 直播应用创建
登录成功点击应用列表选择创建应用




输入应用名称等信息
 





创建成功后点击应用进入





需要注意的是应用的OrgName 和AppName这两个是以后都需要用到的两个参数变量




3、 直播创建
1)在创建直播之前需要对应用进行设置首先需要设置应用的直播流地址
第一步获取应用管理员的Tokencurl -X POST "https://a1.easemob.com/[应用OrgName]/[应用AppName]/token" -d '{"grant_type":"client_credentials","client_id":"[应用client_id]","client_secret":"[应用] client_secret"}'返回格式{
"access_token":"YWMtWY779DgJEeS2h9OR7fw4QgAAAUmO4Qukwd9cfJSpkWHiOa7MCSk0MrkVIco",
"expires_in":5184000,
"application":"c03b3e30-046a-11e4-8ed1-5701cdaaa0e4"












第二步设置直播流地址curl -X POST -H "Authorization: Bearer [管理员Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms/stream_url -d '{"pc_pull":"[pc拉流地址]","pc_push":"[pc推流地址]","mobile_pull":"[手机拉流地址]","mobile_push":"[手机推流地址]"}'"成功返回格式:{
"action": "post",
"application": "e1a09de0-0e03-11e7-ad8e-a1d913615409",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"pc_pull": true,
"mobile_push": true,
"mobile_pull": true,
"pc_push": true
},
"timestamp": 1494084474885,
"duration": 1,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












2)创建主播
点击IM用户





点击注册IM用户





填写用户信息





创建用户的过程同样也可以通过REST API形式进行curl -X POST -i " https://a1.easemob.com/[应用OrgName]/[应用AppName]/users" -d '{"username":"[用户名]","password":"[密码]"}'
注:应用必须为开放注册





将注册的用户添加为主播curl -X POST -H "Authorization: [管理员Token]" https://a1.easemob.com/[应用OrgName]/[应用AppName]/super_admin -d'{"superadmin":"[IM用户名]"}'返回结果示例:{
"action": "post",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"result": "success"
},
"timestamp": 1496236798886,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












3)创建直播
点击直播





点击新建房间





填写房间信息




创建房间同时也可以使用REST API形式进行详情可以查看http://docs.easemob.com/im/live/server-integration环信官方文档。
4、 小程序demo集成使用
小程序直播购物demo集成官方WebIM SDK详情请查看https://github.com/easemob/webim-weixin-xcx
Demo具体配置如下
打开demo 下sdk配置文件





修改appkey为自己应用的appkey





打开pages/live/index.js修改房间默认拉流地址及直播间房间号





四、 扩展说明
Demo中房间为固定测试房间,实际使用中应获取环信直播的房间信息及房间列表。具体如下:
获取直播间列表:curl -X GET -H "Authorization: Bearer [用户Token]" https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms?ongoing=true&limit=[获取数量]&cursor=[游标地址(不填写为充开始查询)]
响应:{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"params": {
"cursor": [
"ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6MzE"
],
"ongoing": [
"true"
],
"limit": [
"2"
]
},
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": [
{
"id": "1924",
"chatroom_id": "17177265635330",
"title": "具体了",
"desc": "就咯",
"startTime": 1495779917352,
"endTime": 1495779917352,
"anchor": "wuls",
"gift_count": 0,
"praise_count": 0,
"current_user_count": 8,
"max_user_count": 9,
"status": "ongoing",
"cover_picture_url": "",
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1"
},
{
"id": "1922",
"chatroom_id": "17175003856897",
"title": "香山",
"desc": "随便",
"startTime": 1495777760957,
"endTime": 1495777760957,
"anchor": "sx001",
"gift_count": 0,
"praise_count": 8,
"current_user_count": 1,
"max_user_count": 3,
"status": "ongoing",
"cover_picture_url": "http://127.0.0.1:8080/easemob- ... ot%3B,
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1"
}
],
"timestamp": 1496303336669,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"cursor": "ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6NDk",
"count": 2
}












获取直播间详情:curl -X GET -H "Authorization: Bearer [用户Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/[房间id]/status"响应:{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"liveRoomID": "1946",
"status": "ongoing"
},
"timestamp": 1496234759930,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"count": 0
}














 
使用环信直播购物小程序遇到任何问题欢迎跟帖讨论。 查看全部
今天你看直播了吗?
拥有10亿微信生态用户的小程序已经成为了继移动互联后的又一个现象级风口,随着微信小程序对外开放实时音视频录制及播放等更多连接能力,小程序与直播强强联合,在各行各业找到了非常多的玩法,小程序直播相比微信直播和APP直播更加简洁、流畅、低延时、多入口等众多优势迅速向商业直播领域及泛娱乐直播领域蔓延。从小游戏、内容付费、工具、大数据、社交电商创业者到传统品牌商们,都在努力搭上小程序直播这辆快车,以免错过微信生态里新的流量洼地。
 
微信图片_20180725162426.jpg


作为一名环信生态圈资深开发者,本着对技术的热衷,对环信的眷恋和对党的忠诚,基于环信即时通讯云写了“直播购物小程序”,目前项目源码已全部免费开放,希望对有需求的企业和开发者提供一个思路和参考。
直播购物小程序源码github地址:https://github.com/YuTongNetworkTechnology/wechat_live/tree/master 
git打不开可直接点下面链接下载



预览图.jpg

直播购物小程序运行预览图 
 
小程序体验指南(仅需两步):
 
1、下载微信小程序开发工具,下载地址:https://developers.weixin.qq.c ... .html 
 
Catch9A07(07-20-17-38-30).jpg

2、导入源码:将附件的源码解压直接导入 


Catch1C69(07-20-17-38-30).jpg


环信小程序直播技术文档
一、 使用的技术
1、 环信IM直播室。
2、 微信小程序实时音视频播放组件live-player。
3、 推流软件(obs、易推流)等推流。
4、 视频流服务器(UCLOUD、七牛、腾讯)等视频流服务器。
二、 系统使用流程。
1、 视频推流软件将视频流推到流服务器。
2、 打开视频直播demo小程序注册环信账号。
3、 进入软件直播室进行测试。
三、 技术流程及使用的SDk
1、 注册环信账号
打开https://www.easemob.com/ 环信官网,点击右上角注册按钮,选择[注册即时通讯云]
1.png

填写对相关信息进行注册

2.png

注册成功后进行登录
3.png

注:新注册用户需进行账号的认证。
2、 直播应用创建
登录成功点击应用列表选择创建应用
4.png

输入应用名称等信息
 

5.png

创建成功后点击应用进入

6.png

需要注意的是应用的OrgName 和AppName这两个是以后都需要用到的两个参数变量
7.png

3、 直播创建
1)在创建直播之前需要对应用进行设置首先需要设置应用的直播流地址
第一步获取应用管理员的Token
curl -X POST "https://a1.easemob.com/[应用OrgName]/[应用AppName]/token" -d '{"grant_type":"client_credentials","client_id":"[应用client_id]","client_secret":"[应用] client_secret"}'
返回格式
{
"access_token":"YWMtWY779DgJEeS2h9OR7fw4QgAAAUmO4Qukwd9cfJSpkWHiOa7MCSk0MrkVIco",
"expires_in":5184000,
"application":"c03b3e30-046a-11e4-8ed1-5701cdaaa0e4"












第二步设置直播流地址
curl -X POST -H "Authorization: Bearer [管理员Token]"  " https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms/stream_url -d '{"pc_pull":"[pc拉流地址]","pc_push":"[pc推流地址]","mobile_pull":"[手机拉流地址]","mobile_push":"[手机推流地址]"}'"
成功返回格式:
{
"action": "post",
"application": "e1a09de0-0e03-11e7-ad8e-a1d913615409",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"pc_pull": true,
"mobile_push": true,
"mobile_pull": true,
"pc_push": true
},
"timestamp": 1494084474885,
"duration": 1,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












2)创建主播
点击IM用户

8.png

点击注册IM用户

9.png

填写用户信息

10.png

创建用户的过程同样也可以通过REST API形式进行
curl -X POST -i " https://a1.easemob.com/[应用OrgName]/[应用AppName]/users" -d '{"username":"[用户名]","password":"[密码]"}'

注:应用必须为开放注册

11.png

将注册的用户添加为主播
curl -X POST -H "Authorization: [管理员Token]"  https://a1.easemob.com/[应用OrgName]/[应用AppName]/super_admin -d'{"superadmin":"[IM用户名]"}'
返回结果示例:
{
"action": "post",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"result": "success"
},
"timestamp": 1496236798886,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












3)创建直播
点击直播

12.png

点击新建房间

13.png

填写房间信息
14.png

创建房间同时也可以使用REST API形式进行详情可以查看http://docs.easemob.com/im/live/server-integration环信官方文档。
4、 小程序demo集成使用
小程序直播购物demo集成官方WebIM SDK详情请查看https://github.com/easemob/webim-weixin-xcx
Demo具体配置如下
打开demo 下sdk配置文件

15.png

修改appkey为自己应用的appkey

16.png

打开pages/live/index.js修改房间默认拉流地址及直播间房间号

17.png

四、 扩展说明
Demo中房间为固定测试房间,实际使用中应获取环信直播的房间信息及房间列表。具体如下:
获取直播间列表:
curl -X GET -H "Authorization: Bearer  [用户Token]"  https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms?ongoing=true&limit=[获取数量]&cursor=[游标地址(不填写为充开始查询)]

响应:
{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"params": {
"cursor": [
"ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6MzE"
],
"ongoing": [
"true"
],
"limit": [
"2"
]
},
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": [
{
"id": "1924",
"chatroom_id": "17177265635330",
"title": "具体了",
"desc": "就咯",
"startTime": 1495779917352,
"endTime": 1495779917352,
"anchor": "wuls",
"gift_count": 0,
"praise_count": 0,
"current_user_count": 8,
"max_user_count": 9,
"status": "ongoing",
"cover_picture_url": "",
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1"
},
{
"id": "1922",
"chatroom_id": "17175003856897",
"title": "香山",
"desc": "随便",
"startTime": 1495777760957,
"endTime": 1495777760957,
"anchor": "sx001",
"gift_count": 0,
"praise_count": 8,
"current_user_count": 1,
"max_user_count": 3,
"status": "ongoing",
"cover_picture_url": "http://127.0.0.1:8080/easemob- ... ot%3B,
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1"
}
],
"timestamp": 1496303336669,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"cursor": "ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6NDk",
"count": 2
}












获取直播间详情:
curl -X GET -H "Authorization: Bearer [用户Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/[房间id]/status"
响应:
{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"liveRoomID": "1946",
"status": "ongoing"
},
"timestamp": 1496234759930,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"count": 0
}














 
使用环信直播购物小程序遇到任何问题欢迎跟帖讨论。
19
评论

【新手快速入门】集成环信常见问题+解决方案汇总

dujiepeng 发表了文章 • 26106 次浏览 • 2017-05-22 15:51 • 来自相关话题

   这里整理了集成环信的常见问题和一些功能的实现思路,希望能帮助到大家。感谢热心的开发者贡献,大家在观看过程中有不明白的地方欢迎直接跟帖咨询。
 
ios篇
APNs证书创建和上传到环信后台头像昵称的简述和处理方案音视频离线推送Demo实现环信服务器聊天记录保存多久?离线收不到好友请求IOS中环信聊天窗口如何实现文件发送和预览的功能ios集成常见问题环信推送的一些常见问题实现名片|红包|话题聊天室等自定义cell
 
Android篇
Android sdk 的两种导入方式环信3.0SDK集成小米推送教程EaseUI库中V4、v7包冲突解决方案Android EaseUI里的百度地图替换为高德地图android扩展消息(名片集成)关于会话列表的置顶聊天java.lang.UnsatisfiedLinkError: 的问题android 端 app 后台被杀死收不到消息的解决方案
昵称头像篇
android中如何显示开发者服务器上的昵称和头像 Android中显示头像(接上一篇文章看)环信(Android)设置头像和昵称的方法(最简单暴力的基于环信demo的集成)IOS中如何显示开发者服务器上的昵称和头像【环信公开课第12期视频回放】-所有关于环信IM昵称头像的问题听这课就够了
 
直播篇
一言不合你就搞个直播APP
 
客服集成
IM-SDK和客服SDK并存开发指南—Android篇IM-SDK和客服SDK并存开发指南—iOS篇
 
开源项目
Android简版demoios简版demo凡信2.0:超仿微信的开源项目 凡信3.0:携直播和红包而来高仿微信:Github 3,515 Star方圆十里:环信编程大赛冠军项目泛聊:定一个小目标写一个QQSlack聊天机器人:一天时间做一个聊天机器人TV视频通话:在电视上视频通话视频通话:Android手机视频通话酷信:ios高仿微信公众号助手:与订阅用户聊天沟通
 
持续更新ing...小伙伴们还有什么想知道欢迎跟帖提出。
  查看全部
   这里整理了集成环信的常见问题和一些功能的实现思路,希望能帮助到大家。感谢热心的开发者贡献,大家在观看过程中有不明白的地方欢迎直接跟帖咨询。
 
ios篇

 
Android篇

昵称头像篇

 
直播篇
  1. 一言不合你就搞个直播APP

 
客服集成
  1. IM-SDK和客服SDK并存开发指南—Android篇
  2. IM-SDK和客服SDK并存开发指南—iOS篇

 
开源项目

 
持续更新ing...小伙伴们还有什么想知道欢迎跟帖提出。
 
1
评论

如何构建分布式SFU/MCU媒体服务器? SFU_MCU

beyond 发表了文章 • 571 次浏览 • 2019-11-26 14:40 • 来自相关话题

本文来自英特尔实时通信解决方案架构师 段先德在LiveVideoStackCon2019上海大会的分享,详细介绍了英特尔在进行分布式SFU/MCU媒体服务器的架构设计中秉持的一些设计原则以及关键问题的解决思路。
大家好,我是来自英特尔上海研发中心的段先德。从2014年开始主要做基于WebRTC的实时通信和统一通信解决方案。对于实时通讯来说WebRTC技术是一个革命性的存在。2014年4月英特尔发布了Intel® Collaboration Suite for WebRTC,这是一款可免费使用的包含服务器侧程序和客户端SDK的完整解决方案。经过多年的迭代更新,当前最新发布的是4.2版本。

1. Requirements and Design Principles

本次分享的内容主要分为三个部分,首先介绍英特尔ICS for WebRTC项目中要解决的问题;其次介绍我们在解决这些问题的时候的指导思想和整体设计原则;最后介绍我们的解决方案目前的状态以及当下和近期要做的一些事情。

1.1 Functional Requirements






我们项目团队最初的出发点是希望能做一套够达到一般功能性要求的基于互联网的视频会议解决方案。譬如可以支持WebRTC和SIP终端,实现接入到同一个会议中。SIP主要针对的是存量设备,重点是对WebRTC终端的支持。WebRTC接入相比于很多以前存量的企业视频会议解决方案有很多的突破,从2011年以后Chrome在端多媒体系统,弱网对抗方面以及音视频处理这方面一直在持续的改进。

英特尔很早就注意到在WebRTC时代,亟需一个统一的终端和服务器侧的解决方案。我们需要把企业内外的一些移动终端、桌面应用、浏览器、传统的SIP终端设备都支持起来,需要支持NAT穿越和屏幕共享,需要支持服务器侧音视频录制,等等。这里面很多功能性需求通过传统SIP的解决方案做起来很不方便或者成本很高,但是在WebRTC时代,在基于互联网应用的技术思路下,可以很便捷、很优雅地解决这些问题,于是我们在2014年做了ICS for WebRTC v1.0。之后在2016年和2017年之间直播类的应用大爆发使得有些客户希望我们的解决方案里面能够支持直播类场景,把实时互动场景下的音视频流通过RTMP/RTSP/HLS/Dash推送到现有的CDN网络里面去。基于这类需求,我们在功能性方面增加了互动Streaming的能力。

2018年到现在,直播的用户体验要求越来越高,客户希望主播和粉丝或者观众之间的互动能够非常平滑的切换,同时端到端的时延也能够做得更好,也就是希望做到保证端到端的实时性的前提下,在单个呼叫里支持海量的用户连接。这就要求服务器侧系统既要有非常大的“扇出”能力,要支持终端连接在“发布者”和“订阅者”之间非常平滑地进行切换。我们目前正在做的就是把目前的解决方案扩展到这种能够支持大规模并发的“实时互动广播”,初步目标是单个呼叫里达到百万以上的并发连接,而且端到端的时延能够全球控制在300毫秒以内。关于端到端时延,我们在国内互联网上做过一些小规模的测试,测试结果的时延是150毫秒以内。我们还希望这个解决方案能够很方便封装成类似于CDN的服务访问接口或者形式,以便集成到客户现有的直播解决方案中去。

我们当前的解决方案已经具备了非常灵活的服务器侧媒体处理,服务器端可以做音视频的混音混流,比如说当前的一个呼叫里面有十几个参与方,有的参与方希望订阅呼叫中其他参与方发布的原始流,有的参与方希望订阅所有或部分参与方的mix流,有的参与方希望订阅符合自己对codec、分辨率、帧率、码率等定制化要求的转发流,我们当前的解决方案已经可以很好地支持这些需求。

1.2 Nonfunctional Requirements






如果仅仅是为了达到前面所讲的各种功能性需求,随便选择一个现有的开源框架去改改,再自己从头写一些功能模块拼凑一下,总可以整出一个PoC的版本或可以初步走向产品的东西。如果是要严肃地做一个打算把它放到生产环境去运营的产品级别的东西,真正考验这个解决方案的生命力的其实是它在非功能性需求方面的取舍和功力。即使是选择现有的开源框架去做产品,这个框架对非功能性方面的考量也是最重要的决定因素。

在非功能性方面主要关注的点有三个方面。

一是系统的可扩展性,它的服务部署规模可大可小,可以小到在一台英特尔®️ 酷睿™️i7的PC上部署使用,大到一个集群几百台甚至上千台机器组成一个大的cluster上部署使用。另外呼叫的参与方式可以是两三个人的讨论会,或者十几个人一般视频会议,又或者是几十人的在线课堂。部署时可以在当前的系统容量不足时在不中断业务的前提下增加或者删减当前部署的规模,达到很灵活的Scale in/Scale out。

二是容错性,容错能力大多描述都比较抽象,但是落实到系统在做设计的时候要考虑的东西就是非常具体的设计决策,在系统设计里面我们会强调甚至固执的坚持每一个部件都可能会出错,运行时都会发生crash,这就需要在流程设计或者一般逻辑里面handle这些问题,在系统发生部分失效的时候,要能够做到自动恢复或服务优雅降级。

三是分布式部署,单台机器上单实例的部署是不可能做容错的,只有分布式的部署才能够做到。我们要求允许把任何部件部署在数据中心的多台机器上面。我们现在进一步的要求是要能够把任何部件部署在多个数据中心,进行跨数据中心的分布式部署。

2.Unified Media Spread Model UMSM)
2.1 Modularization at Runtime






要满足上述的各种功能性和非功能性需求,就需要在概念模型上对系统的各个部件进行足够的抽象,将逻辑上独立的部件封装到运行时独立的模块里面——即模块化。不管是从单一职责的角度来说,还是从系统的可组合性来说,模块化是自始至终不能打破的一个原则,是我们当前系统——也是很多复杂系统进行架构的第一原则。在我们的系统设计中,对于跟客户端交互的部件来说,要把信令和媒体分开。对于媒体部分来说,媒体的接入部分和处理部分一定是分开的,直接和用户打交道的部分和后台内部的一些处理部件,不管是从单一职责角度来讲还是从面向接口的健壮性要求来讲都必须把它们分开。

我们的服务器侧系统在运行时可以分成五大块。

第一块就是跟客户端进行信令交互的部件,即图中的WebRTC Portal和SIP Portal。他们跟WebRTC客户端和SIP终端进行信令交互。值得注意的一点是WebRTC标准对信令交互的格式和通道没有规定,我们采用的是一种承载在socket.io通道中的私有协议。

第二块是跟客户端进行音视频媒体交互的部件,即图中的WebRTC Agent、Streaming Agent、SIP Agent和Recording Agent。其中WebRTC Agent负责跟客户端之间建立PeerConnection连接,SIP Agent跟SIP终端RTP流进行传输,Streaming Agent是针对RTSP/RTMP/HLS/Dash流,我们可以把IPCamera的RTSP流作为输入直接拉到系统里面来,也可以把系统里面任何一个输入流/合成流/转码后的流作为输出推送到RTMP Server上去,Recording虽然是完全发生在服务器侧的行为,但实际上在概念层次上面是更接近于流的输出。所以在概念模型里我们也把Recording Agent当做媒体接出部件,以达到概念模型的一致性。

第三块是媒体处理的部件,即图中的Audio Agent和Video Agent。Audio Agent是进行音频混音转码工作的部件,Video Agent是视频的合屏和转码的部件,这些所有的部件都是单独部署独立进程在运行。

第四块是呼叫控制的部件,即图中的Conference Agent。我们的系统还是将多方实时音视频通信作为场景基础,Conference Agent就是一通呼叫的总控制部件,它负责room中的参与者、流、订阅关系的控制和管理。对于像远程教育、远程医疗、远程协助之类的其他场景,我们主要是通过对Conference Agent来进行拓展和增强去支持。

第五块就是一些支持部件。整个服务器系统在运行和单机运行时都是cluster形式,Cluster Manager就是一个简单的cluster管理器。视频会议场景中会有一些room的预配置和管理,room的配置数据存放在MongoDB中,管理员都是通过OAM UI通过RESTful API访问Management API部件实现数据访问并受理REST请求。另外各个部件之间的rpc是架设在RabbitMQ消息队列上的。

2.2 Strong Isolation






第二个原则就是要做强隔离。在系统里面坚持执行的原则就是要做强隔离,运行时一定是把看到的逻辑上面独立部件,把它在物理上也做成完全独立的运行时进程。比如像信令受理部件和信令执行部件就是分别独立的进程。这样做使得信令受理部件可以独立于呼叫控制里面的业务逻辑而存在。同理媒体接入部件和媒体处理部件也是分别独立进程。这里的进程就是OS语义上面进程,是我们服务器侧系统构建的基本元素,是生命体的细胞,不同的部件之间进行通讯唯一的方式就是message passing(消息传递)。在概念模型里面看的得到部件都是用单独的Worker进程来处理一个独立的Job。比方说一个Video Agent生成出来的Video Node,它的职责要么是做一个视频混流器,要么是做一个视频转码器,单独运行,独立工作。这样做一方面是进行错误隔离一个部件中产生的异常不会传染影响其他部件,一方面是各个运行时部件可以进行运行时单独进行升级替换。

2.3 Hierarchy in Media Accessing/Processing






第三个原则就是层次化。具体体现在在媒体接入和媒体处理的一些部件的设计和实现上,这些部件在南北(纵)向上面有明确的层次划分,自下而上分为包交互层、帧交互层和内容操作层。以媒体接入部件为例,我们服务器侧系统需要跟各种外围系统和终端进行媒体交互,有的媒体是通过RTP/SRTP包的形式输入、输出,有的媒体是直接以AVStream的行书输出、输出。当媒体进入到我们服务器侧系统内部以后,我们希望有一个统一的格式让它在所有的媒体相关部件之间自由流转,所以我们就定义了统一的MediaFrame格式,所有输入的媒体在媒体接入部件上被组装成MediaFrame。处理MediaFrame的逻辑我们把它放在帧交互层,与客户端进行RTP/SRTP交互的逻辑我们放在包交互层。另外,MediaFrame进入媒体处理部件后,如果涉及到raw格式的操作——譬如合屏、色彩调整、添加水印、替换背景等——我们就把相关逻辑放在内容操作层。

2.4 Media Pipeline in WebRTC Node






设计原则讲起来太枯燥,举两个例子。

第一个是WebRTC Node中的Pipeline结构。在WebRTCNode上面有一个明确的一个界限,广为人知的一些开源的框架里面有一些SFU框架是直接做RTP包的高级转发,而在我们的解决方案里于所有的外部媒体进入到系统里面会先将它们整理成统一的媒体(帧集的封装)之后在各个结点之间进行传输。除了使得层次分明便于系统横向扩展以外,另外一大好处就是把RTP传输相关的事务都终结在媒体接入部件(节点)上,RTP传输中的丢包、乱序等问题的处理不会扩散到系统其它部件。

2.5 Media Pipeline in Video Node (Video Mixer)






第二个例子是视频混流器内部的Pipeline结构。视频混流的部件在Pipeline上面进出都是视频帧,图上紫颜色的模块进出的都是视频已编码的帧,在视频处理部件的内部可以是一些已编码的帧,也可以是一些Scaler和Convertor。使得各个层次的处理器接口非常清楚,便于做成plugable。

2.6 Unified Media Spread Model (UMSM)






前面我们根据系统的功能性和非功能性需求,把系统拆成了一个个松散的部件。那么,怎么把这些部件捏合到一起成为一个有机的系统呢?特别是针对各个媒体接入部件和媒体处理部件之间的媒体交互,我们需要定义一个统一的内部媒体交互模型——我们称之为UMSM。

音视频媒体在系统内部流动,我们采用的是一个“发布-订阅”结构的流基本拓扑。如图所示,系统有一个发布者发布一个流进入到系统里,此时有两个订阅者,其中一个订阅者希望订阅发布的原始流的直接转发流,另外一个订阅者希望订阅房间里面所有的原始流合成流合屏以后的mix流,流的发布者和订阅者的PeerConnection连接建立在不同的WebRTC Node上面,通过PeerConnection进入WebRTC Node的SRTP包流,经过解密,被整理封装成MediaFrame(Audioframe/Videoframe),之后再在不同的部件之间进行传递,如果有订阅者需要的是直接转发流,就把它封装好的音频和视频的帧直接扩散到订阅者所连接的WebRTC Node上面来,如果有订阅者需要合成的流(合屏和混音的流),那么就把混流和混音以后的MediaFrame从AudioNode(Audio Mixer)和VideoNode(Video Mixer)扩散到订阅者所连接的WebRTC Node上。

有了这样一个足够松散的系统内部流扩散结构,无论这些媒体接入部件和媒体处理部件是运行在同一台机器上还是运行在一个数据中心内的不同机器上——甚至运行在位于不同数据中心的不同机器上,都有统一的、一致的流拓扑结构。

2.7 Media Spread Protocol






要实现这样一个流扩散模型,重点要解决两个方面的问题,一个是媒体节点间的传输,另一个是媒体节点的控制。

媒体节点间的传输是面向连接的,因为扩散链路都可能持续比较长的时间,且一般服务器侧部件的部署环境的网络条件是可控的,有利于保障传输质量。另外每一个连接结点间的扩散链路的连接是双向的,因为有可能两个媒体流的接入结点之间存在双向的扩散,以及与媒体流相关的一些feedback信息需要被反向传递,我们希望它能够复用在同一个扩散链路上面。另外我们需要它是可靠的,在以前跟合作伙伴做技术交流的时候他们对于要求流扩散链路必须是可靠的这一点有疑惑。实际上这是一个实时性和可靠性的取舍问题,我们选择在这个环节保证可靠性,而把实时性推给底层去解决,因为如果要在流扩散链路的所有环节处理信号损失,将给上层逻辑带来巨大的复杂性。

2.8 MSP - Transport Control Primitives(WIP)

传输控制就是对于节点间扩散传输链路的控制,目前为了方便在采用的是TCP,在同一数据中心内进行流扩散问题不大,在应用到跨数据中心的部署场景中时,特别是tts和delay比较大的情况下,实际可用的throughput会受比较大的影响,目前仍有一些改进的工作还在进行当中,我们也在调研SCTP和QUIC。

2.9 MSP - Underlying Transport Protocols(TCP vs.QUIC under weak network)






我们在节点间扩散时加一些网损的情况下用TCP和QUIC有做过一些对比测试。QUIC和TCP都是可靠传输,在有网损的时候都会产生一些重传或者是冗余,但是他们不同的拥塞控制策略会对端到端的媒体传递的质量产生不同的影响。我们的对比测试中,发送端是以恒定的码率和帧率(24fps)向服务器侧发送视频流,服务器侧在节点间分别采用TCP和QUIC进行节点间媒体流扩散,图中截取的是相同的网损条件下接收端收到的实际帧率,在5%的丢包和30ms delay时, TCP的帧率就会抖动的非常厉害,在接收端体验就会看到点不流畅,能明显地看到它的卡顿。当加上10%的丢包时波动就跟家剧烈,有时甚至降低到0fps,接收端的用户体验就是非常明的卡顿。相比而言,在QUIC上面还能够看到,接收端的帧率能够更好地坚持在24fps上下,接收端的流畅度更好。总体来看,QUIC是在弱网环境下进行节点间流扩散的一个不错的备选传输。

2.10 MSP - Media Control Primitives






媒体控制的操作对于媒体节点来说,一个publish就是往媒体结点上面发布一路流,给它增加一个input,一个subscribe就是在它上面去增添一个output,linkup就是把一个input和output接续起来,cutoff就把一个input和一个output拆开。对于媒体处理的结点有一些内生的流,generate就是让它产生一路流指定规格(codec、分辨率、帧率、码率、关键帧间隔等),degenerate就是让它取消正在生成中的一个流。

3.Cross DC Media Spread
3.1 Cross DC Media Spread:Relay Node (WIP)






做TCP和QUIC的对比调研目的就是解决跨数据中心通过Internet进行节点间媒体流扩散的实时性(本质是throughput)问题。由于在跨数据中心媒体扩散的时候需要在Internet上面做流扩散,Internet在传输质量上讲没有在数据中心里的效果那么满意,需要找一些基于UDP改进的可靠传输协议去尝试,我们调研过SCTP和QUIC,总体来看QUIC的表现是相当不错的。

同时为了减少同一条流在两个数据中心的多个节点间传输,我们增加了一个Relay Agent(Node)的部件,使得同一条流在两个数据中心之间只需要扩散一次。Relay Agent的另一个作用是进行流扩散的时候的路由控制,譬如一个集团公司的很多分支机房并不是BGP的,需要将流汇聚到指定的BGP机房才能更好地向其他地区数据中心扩散。

3.2 Access Node(Agent) Scheduling






在部署了多个接入节点以后,除了通过增加接入节点来扩充系统的scalability,我们还希望能够利用接入节点的不同地理位置给靠近它的终端用户做就近接入。以WebRTC Agent为例,在部署WebRTC Agent的时候可以指定它的capacity(能力),capacity上面有两个标签,一个是isp,一个是region。用户在进行通信连接请求的时候,它带上isp和region的preference(喜好),系统在进行WebRTC Agent调度的时候会对所有可用的WebRTC Agent的capacity与用户指定的preference进行匹配,找到最满意的接入结点,最后达到就近接入的目的。

在符合preference的候选不止一个时,系统还提供基于work load和历史使用记录进行last-used、least-used、round-robin、random等调度策略,选取符合指定策略的接入节点。

3.3 CDN alike Service






解决了跨数据中心部署的媒体流扩散和调度问题后,我们的解决方案就可以提供更广阔的实时多方音视频通信服务。特别是有了Relay Agent的级联能力后,我们服务器侧系统就可以得到极大的提升,譬如假设单个媒体接入节点的扇出能力是1:1000的话,经过一级级联后就能达到1:100万,经过两级级联后就能达到1:10亿,已经堪比一般CDN的扇出能力了。而CDN的就是本质是一个分布式的cache系统,cache是实时应用的天敌。许多既要求海量扇出比,又要求实时性,并且要随时平滑进行流拓扑切换的场景下,CDN就显得无能为力了,而我们的解决方案将覆盖这些场景,特别是在5G和IoT的时代。

原文发布于微信公众号 - LiveVideoStack(livevideostack) 查看全部
本文来自英特尔实时通信解决方案架构师 段先德在LiveVideoStackCon2019上海大会的分享,详细介绍了英特尔在进行分布式SFU/MCU媒体服务器的架构设计中秉持的一些设计原则以及关键问题的解决思路。
大家好,我是来自英特尔上海研发中心的段先德。从2014年开始主要做基于WebRTC的实时通信和统一通信解决方案。对于实时通讯来说WebRTC技术是一个革命性的存在。2014年4月英特尔发布了Intel® Collaboration Suite for WebRTC,这是一款可免费使用的包含服务器侧程序和客户端SDK的完整解决方案。经过多年的迭代更新,当前最新发布的是4.2版本。

1. Requirements and Design Principles

本次分享的内容主要分为三个部分,首先介绍英特尔ICS for WebRTC项目中要解决的问题;其次介绍我们在解决这些问题的时候的指导思想和整体设计原则;最后介绍我们的解决方案目前的状态以及当下和近期要做的一些事情。

1.1 Functional Requirements

1.jpg


我们项目团队最初的出发点是希望能做一套够达到一般功能性要求的基于互联网的视频会议解决方案。譬如可以支持WebRTC和SIP终端,实现接入到同一个会议中。SIP主要针对的是存量设备,重点是对WebRTC终端的支持。WebRTC接入相比于很多以前存量的企业视频会议解决方案有很多的突破,从2011年以后Chrome在端多媒体系统,弱网对抗方面以及音视频处理这方面一直在持续的改进。

英特尔很早就注意到在WebRTC时代,亟需一个统一的终端和服务器侧的解决方案。我们需要把企业内外的一些移动终端、桌面应用、浏览器、传统的SIP终端设备都支持起来,需要支持NAT穿越和屏幕共享,需要支持服务器侧音视频录制,等等。这里面很多功能性需求通过传统SIP的解决方案做起来很不方便或者成本很高,但是在WebRTC时代,在基于互联网应用的技术思路下,可以很便捷、很优雅地解决这些问题,于是我们在2014年做了ICS for WebRTC v1.0。之后在2016年和2017年之间直播类的应用大爆发使得有些客户希望我们的解决方案里面能够支持直播类场景,把实时互动场景下的音视频流通过RTMP/RTSP/HLS/Dash推送到现有的CDN网络里面去。基于这类需求,我们在功能性方面增加了互动Streaming的能力。

2018年到现在,直播的用户体验要求越来越高,客户希望主播和粉丝或者观众之间的互动能够非常平滑的切换,同时端到端的时延也能够做得更好,也就是希望做到保证端到端的实时性的前提下,在单个呼叫里支持海量的用户连接。这就要求服务器侧系统既要有非常大的“扇出”能力,要支持终端连接在“发布者”和“订阅者”之间非常平滑地进行切换。我们目前正在做的就是把目前的解决方案扩展到这种能够支持大规模并发的“实时互动广播”,初步目标是单个呼叫里达到百万以上的并发连接,而且端到端的时延能够全球控制在300毫秒以内。关于端到端时延,我们在国内互联网上做过一些小规模的测试,测试结果的时延是150毫秒以内。我们还希望这个解决方案能够很方便封装成类似于CDN的服务访问接口或者形式,以便集成到客户现有的直播解决方案中去。

我们当前的解决方案已经具备了非常灵活的服务器侧媒体处理,服务器端可以做音视频的混音混流,比如说当前的一个呼叫里面有十几个参与方,有的参与方希望订阅呼叫中其他参与方发布的原始流,有的参与方希望订阅所有或部分参与方的mix流,有的参与方希望订阅符合自己对codec、分辨率、帧率、码率等定制化要求的转发流,我们当前的解决方案已经可以很好地支持这些需求。

1.2 Nonfunctional Requirements

2.jpg


如果仅仅是为了达到前面所讲的各种功能性需求,随便选择一个现有的开源框架去改改,再自己从头写一些功能模块拼凑一下,总可以整出一个PoC的版本或可以初步走向产品的东西。如果是要严肃地做一个打算把它放到生产环境去运营的产品级别的东西,真正考验这个解决方案的生命力的其实是它在非功能性需求方面的取舍和功力。即使是选择现有的开源框架去做产品,这个框架对非功能性方面的考量也是最重要的决定因素。

在非功能性方面主要关注的点有三个方面。

一是系统的可扩展性,它的服务部署规模可大可小,可以小到在一台英特尔®️ 酷睿™️i7的PC上部署使用,大到一个集群几百台甚至上千台机器组成一个大的cluster上部署使用。另外呼叫的参与方式可以是两三个人的讨论会,或者十几个人一般视频会议,又或者是几十人的在线课堂。部署时可以在当前的系统容量不足时在不中断业务的前提下增加或者删减当前部署的规模,达到很灵活的Scale in/Scale out。

二是容错性,容错能力大多描述都比较抽象,但是落实到系统在做设计的时候要考虑的东西就是非常具体的设计决策,在系统设计里面我们会强调甚至固执的坚持每一个部件都可能会出错,运行时都会发生crash,这就需要在流程设计或者一般逻辑里面handle这些问题,在系统发生部分失效的时候,要能够做到自动恢复或服务优雅降级。

三是分布式部署,单台机器上单实例的部署是不可能做容错的,只有分布式的部署才能够做到。我们要求允许把任何部件部署在数据中心的多台机器上面。我们现在进一步的要求是要能够把任何部件部署在多个数据中心,进行跨数据中心的分布式部署。

2.Unified Media Spread Model UMSM)
2.1 Modularization at Runtime

3.jpg


要满足上述的各种功能性和非功能性需求,就需要在概念模型上对系统的各个部件进行足够的抽象,将逻辑上独立的部件封装到运行时独立的模块里面——即模块化。不管是从单一职责的角度来说,还是从系统的可组合性来说,模块化是自始至终不能打破的一个原则,是我们当前系统——也是很多复杂系统进行架构的第一原则。在我们的系统设计中,对于跟客户端交互的部件来说,要把信令和媒体分开。对于媒体部分来说,媒体的接入部分和处理部分一定是分开的,直接和用户打交道的部分和后台内部的一些处理部件,不管是从单一职责角度来讲还是从面向接口的健壮性要求来讲都必须把它们分开。

我们的服务器侧系统在运行时可以分成五大块。

第一块就是跟客户端进行信令交互的部件,即图中的WebRTC Portal和SIP Portal。他们跟WebRTC客户端和SIP终端进行信令交互。值得注意的一点是WebRTC标准对信令交互的格式和通道没有规定,我们采用的是一种承载在socket.io通道中的私有协议。

第二块是跟客户端进行音视频媒体交互的部件,即图中的WebRTC Agent、Streaming Agent、SIP Agent和Recording Agent。其中WebRTC Agent负责跟客户端之间建立PeerConnection连接,SIP Agent跟SIP终端RTP流进行传输,Streaming Agent是针对RTSP/RTMP/HLS/Dash流,我们可以把IPCamera的RTSP流作为输入直接拉到系统里面来,也可以把系统里面任何一个输入流/合成流/转码后的流作为输出推送到RTMP Server上去,Recording虽然是完全发生在服务器侧的行为,但实际上在概念层次上面是更接近于流的输出。所以在概念模型里我们也把Recording Agent当做媒体接出部件,以达到概念模型的一致性。

第三块是媒体处理的部件,即图中的Audio Agent和Video Agent。Audio Agent是进行音频混音转码工作的部件,Video Agent是视频的合屏和转码的部件,这些所有的部件都是单独部署独立进程在运行。

第四块是呼叫控制的部件,即图中的Conference Agent。我们的系统还是将多方实时音视频通信作为场景基础,Conference Agent就是一通呼叫的总控制部件,它负责room中的参与者、流、订阅关系的控制和管理。对于像远程教育、远程医疗、远程协助之类的其他场景,我们主要是通过对Conference Agent来进行拓展和增强去支持。

第五块就是一些支持部件。整个服务器系统在运行和单机运行时都是cluster形式,Cluster Manager就是一个简单的cluster管理器。视频会议场景中会有一些room的预配置和管理,room的配置数据存放在MongoDB中,管理员都是通过OAM UI通过RESTful API访问Management API部件实现数据访问并受理REST请求。另外各个部件之间的rpc是架设在RabbitMQ消息队列上的。

2.2 Strong Isolation

4.jpg


第二个原则就是要做强隔离。在系统里面坚持执行的原则就是要做强隔离,运行时一定是把看到的逻辑上面独立部件,把它在物理上也做成完全独立的运行时进程。比如像信令受理部件和信令执行部件就是分别独立的进程。这样做使得信令受理部件可以独立于呼叫控制里面的业务逻辑而存在。同理媒体接入部件和媒体处理部件也是分别独立进程。这里的进程就是OS语义上面进程,是我们服务器侧系统构建的基本元素,是生命体的细胞,不同的部件之间进行通讯唯一的方式就是message passing(消息传递)。在概念模型里面看的得到部件都是用单独的Worker进程来处理一个独立的Job。比方说一个Video Agent生成出来的Video Node,它的职责要么是做一个视频混流器,要么是做一个视频转码器,单独运行,独立工作。这样做一方面是进行错误隔离一个部件中产生的异常不会传染影响其他部件,一方面是各个运行时部件可以进行运行时单独进行升级替换。

2.3 Hierarchy in Media Accessing/Processing

5.jpg


第三个原则就是层次化。具体体现在在媒体接入和媒体处理的一些部件的设计和实现上,这些部件在南北(纵)向上面有明确的层次划分,自下而上分为包交互层、帧交互层和内容操作层。以媒体接入部件为例,我们服务器侧系统需要跟各种外围系统和终端进行媒体交互,有的媒体是通过RTP/SRTP包的形式输入、输出,有的媒体是直接以AVStream的行书输出、输出。当媒体进入到我们服务器侧系统内部以后,我们希望有一个统一的格式让它在所有的媒体相关部件之间自由流转,所以我们就定义了统一的MediaFrame格式,所有输入的媒体在媒体接入部件上被组装成MediaFrame。处理MediaFrame的逻辑我们把它放在帧交互层,与客户端进行RTP/SRTP交互的逻辑我们放在包交互层。另外,MediaFrame进入媒体处理部件后,如果涉及到raw格式的操作——譬如合屏、色彩调整、添加水印、替换背景等——我们就把相关逻辑放在内容操作层。

2.4 Media Pipeline in WebRTC Node

6.jpg


设计原则讲起来太枯燥,举两个例子。

第一个是WebRTC Node中的Pipeline结构。在WebRTCNode上面有一个明确的一个界限,广为人知的一些开源的框架里面有一些SFU框架是直接做RTP包的高级转发,而在我们的解决方案里于所有的外部媒体进入到系统里面会先将它们整理成统一的媒体(帧集的封装)之后在各个结点之间进行传输。除了使得层次分明便于系统横向扩展以外,另外一大好处就是把RTP传输相关的事务都终结在媒体接入部件(节点)上,RTP传输中的丢包、乱序等问题的处理不会扩散到系统其它部件。

2.5 Media Pipeline in Video Node (Video Mixer)

7.jpg


第二个例子是视频混流器内部的Pipeline结构。视频混流的部件在Pipeline上面进出都是视频帧,图上紫颜色的模块进出的都是视频已编码的帧,在视频处理部件的内部可以是一些已编码的帧,也可以是一些Scaler和Convertor。使得各个层次的处理器接口非常清楚,便于做成plugable。

2.6 Unified Media Spread Model (UMSM)

8.jpg


前面我们根据系统的功能性和非功能性需求,把系统拆成了一个个松散的部件。那么,怎么把这些部件捏合到一起成为一个有机的系统呢?特别是针对各个媒体接入部件和媒体处理部件之间的媒体交互,我们需要定义一个统一的内部媒体交互模型——我们称之为UMSM。

音视频媒体在系统内部流动,我们采用的是一个“发布-订阅”结构的流基本拓扑。如图所示,系统有一个发布者发布一个流进入到系统里,此时有两个订阅者,其中一个订阅者希望订阅发布的原始流的直接转发流,另外一个订阅者希望订阅房间里面所有的原始流合成流合屏以后的mix流,流的发布者和订阅者的PeerConnection连接建立在不同的WebRTC Node上面,通过PeerConnection进入WebRTC Node的SRTP包流,经过解密,被整理封装成MediaFrame(Audioframe/Videoframe),之后再在不同的部件之间进行传递,如果有订阅者需要的是直接转发流,就把它封装好的音频和视频的帧直接扩散到订阅者所连接的WebRTC Node上面来,如果有订阅者需要合成的流(合屏和混音的流),那么就把混流和混音以后的MediaFrame从AudioNode(Audio Mixer)和VideoNode(Video Mixer)扩散到订阅者所连接的WebRTC Node上。

有了这样一个足够松散的系统内部流扩散结构,无论这些媒体接入部件和媒体处理部件是运行在同一台机器上还是运行在一个数据中心内的不同机器上——甚至运行在位于不同数据中心的不同机器上,都有统一的、一致的流拓扑结构。

2.7 Media Spread Protocol

9.jpg


要实现这样一个流扩散模型,重点要解决两个方面的问题,一个是媒体节点间的传输,另一个是媒体节点的控制。

媒体节点间的传输是面向连接的,因为扩散链路都可能持续比较长的时间,且一般服务器侧部件的部署环境的网络条件是可控的,有利于保障传输质量。另外每一个连接结点间的扩散链路的连接是双向的,因为有可能两个媒体流的接入结点之间存在双向的扩散,以及与媒体流相关的一些feedback信息需要被反向传递,我们希望它能够复用在同一个扩散链路上面。另外我们需要它是可靠的,在以前跟合作伙伴做技术交流的时候他们对于要求流扩散链路必须是可靠的这一点有疑惑。实际上这是一个实时性和可靠性的取舍问题,我们选择在这个环节保证可靠性,而把实时性推给底层去解决,因为如果要在流扩散链路的所有环节处理信号损失,将给上层逻辑带来巨大的复杂性。

2.8 MSP - Transport Control Primitives(WIP)

传输控制就是对于节点间扩散传输链路的控制,目前为了方便在采用的是TCP,在同一数据中心内进行流扩散问题不大,在应用到跨数据中心的部署场景中时,特别是tts和delay比较大的情况下,实际可用的throughput会受比较大的影响,目前仍有一些改进的工作还在进行当中,我们也在调研SCTP和QUIC。

2.9 MSP - Underlying Transport Protocols(TCP vs.QUIC under weak network)

11.jpg


我们在节点间扩散时加一些网损的情况下用TCP和QUIC有做过一些对比测试。QUIC和TCP都是可靠传输,在有网损的时候都会产生一些重传或者是冗余,但是他们不同的拥塞控制策略会对端到端的媒体传递的质量产生不同的影响。我们的对比测试中,发送端是以恒定的码率和帧率(24fps)向服务器侧发送视频流,服务器侧在节点间分别采用TCP和QUIC进行节点间媒体流扩散,图中截取的是相同的网损条件下接收端收到的实际帧率,在5%的丢包和30ms delay时, TCP的帧率就会抖动的非常厉害,在接收端体验就会看到点不流畅,能明显地看到它的卡顿。当加上10%的丢包时波动就跟家剧烈,有时甚至降低到0fps,接收端的用户体验就是非常明的卡顿。相比而言,在QUIC上面还能够看到,接收端的帧率能够更好地坚持在24fps上下,接收端的流畅度更好。总体来看,QUIC是在弱网环境下进行节点间流扩散的一个不错的备选传输。

2.10 MSP - Media Control Primitives

12.jpg


媒体控制的操作对于媒体节点来说,一个publish就是往媒体结点上面发布一路流,给它增加一个input,一个subscribe就是在它上面去增添一个output,linkup就是把一个input和output接续起来,cutoff就把一个input和一个output拆开。对于媒体处理的结点有一些内生的流,generate就是让它产生一路流指定规格(codec、分辨率、帧率、码率、关键帧间隔等),degenerate就是让它取消正在生成中的一个流。

3.Cross DC Media Spread
3.1 Cross DC Media Spread:Relay Node (WIP)

13.jpg


做TCP和QUIC的对比调研目的就是解决跨数据中心通过Internet进行节点间媒体流扩散的实时性(本质是throughput)问题。由于在跨数据中心媒体扩散的时候需要在Internet上面做流扩散,Internet在传输质量上讲没有在数据中心里的效果那么满意,需要找一些基于UDP改进的可靠传输协议去尝试,我们调研过SCTP和QUIC,总体来看QUIC的表现是相当不错的。

同时为了减少同一条流在两个数据中心的多个节点间传输,我们增加了一个Relay Agent(Node)的部件,使得同一条流在两个数据中心之间只需要扩散一次。Relay Agent的另一个作用是进行流扩散的时候的路由控制,譬如一个集团公司的很多分支机房并不是BGP的,需要将流汇聚到指定的BGP机房才能更好地向其他地区数据中心扩散。

3.2 Access Node(Agent) Scheduling

14.jpg


在部署了多个接入节点以后,除了通过增加接入节点来扩充系统的scalability,我们还希望能够利用接入节点的不同地理位置给靠近它的终端用户做就近接入。以WebRTC Agent为例,在部署WebRTC Agent的时候可以指定它的capacity(能力),capacity上面有两个标签,一个是isp,一个是region。用户在进行通信连接请求的时候,它带上isp和region的preference(喜好),系统在进行WebRTC Agent调度的时候会对所有可用的WebRTC Agent的capacity与用户指定的preference进行匹配,找到最满意的接入结点,最后达到就近接入的目的。

在符合preference的候选不止一个时,系统还提供基于work load和历史使用记录进行last-used、least-used、round-robin、random等调度策略,选取符合指定策略的接入节点。

3.3 CDN alike Service

15.jpg


解决了跨数据中心部署的媒体流扩散和调度问题后,我们的解决方案就可以提供更广阔的实时多方音视频通信服务。特别是有了Relay Agent的级联能力后,我们服务器侧系统就可以得到极大的提升,譬如假设单个媒体接入节点的扇出能力是1:1000的话,经过一级级联后就能达到1:100万,经过两级级联后就能达到1:10亿,已经堪比一般CDN的扇出能力了。而CDN的就是本质是一个分布式的cache系统,cache是实时应用的天敌。许多既要求海量扇出比,又要求实时性,并且要随时平滑进行流拓扑切换的场景下,CDN就显得无能为力了,而我们的解决方案将覆盖这些场景,特别是在5G和IoT的时代。

原文发布于微信公众号 - LiveVideoStack(livevideostack)
8
评论

【源码下载】一款使用环信实现的开源灵魂社交APP(含服务器) 猿匹配 开源

beyond 发表了文章 • 13077 次浏览 • 2019-07-01 10:48 • 来自相关话题

#前言
近期,环信热心开发者-穿裤衩闯天下使用环信IM开发了一款实时聊天应用,包含简单的服务器端,现在正式开源给小伙伴们。感兴趣的同学可以一起搞一下哦,详细介绍请往下看。






  上代码
服务器:VMServer
客户端:VMMatch
 
 #VMMatch
猿匹配 —— 国内首个程序猿非严肃婚恋交友应用,让我们一言不合就来场匹配吧
 
#介绍#
首先说下中文名:为什么叫这个名字呢,因为这是一个程序猿(媛)之间匹配交流的应用啊其实这是一个使用环信 IM 开发的一款开源聊天项目,涵盖了时下流行的一些聊天元素,同时已将 IM 功能封装为单独库,可以直接引用,方便使用
项目还处在初期阶段,还有许多功能需要实现,有兴趣的可以一起来
项目资源均来自于互联网,如果有侵权请联系我
 
 #下载体验
猿匹配 小米商店 审核中
猿匹配 Google Play
 
  #项目截图

























  
 #开发环境
项目基本属于在最新的Android开发环境下开发,使用Java8的一些新特性,比如Lambda表达式,
然后项目已经适配Android6.x以上的动态权限适配,以及7.x的文件选择,和8.x的通知提醒等;
· Mac OS 10.14.4
· Android Studio 3.3.2
  #项目模块儿
本项目包含两部分:
一部分是项目主模块app,这部分主要包含了项目的业务逻辑,比如匹配、信息修改、设置等
另一部分是封装成library的vmim,这是为了方便大家引用到自己的项目中做的一步封装,不用再去复杂的复制代码和资源等,
只需要将vmim以module导入到自己的项目中就行了,具体使用方式参见项目app模块儿;
 
  #功能与 TODO
IM部分功能
· [x] 链接监听
· [x] 登录注册
· [x] 会话功能
      。[x] 置顶
      。[x] 标为未读
      。[x] 删除与清空
      。[x] 草稿功能
· [x] 消息功能
      。[x] 下拉加载更多
      。[x] 消息复制(仅文字类消息)
      。[x] 消息删除
      。[x] 文本+Emoji消息收发
      。[x] 大表情消息收发
      。[x] 图片消息
        ~[x] 查看大图
        ~[ ] 保存图片
      。[x] 语音消息
        ~[x] 语音录制
        ~[x] 语音播放(可暂停,波形待优化)
        ~[x] 听筒和扬声器播放切换
      。[x] 语音实时通话功能
      。[x] 视频实时通话功能
      。[x] 通话过程中的娱乐消息收发
        ~[x] 骰子
        ~[x] 石头剪刀布
        ~[x] 大表情
      。[x] 昵称头像处理(通过回调实现)
App部分功能
· [x] 登录注册(包括业务逻辑和 IM 逻辑)
· [x] 匹配
      。[x] 提交匹配信息
      。[x] 拉取匹配信息
· [x] 聊天(这里直接加载 IM 模块儿)
· [x] 我的
      。[x] 个人信息展示
      。[x] 上传头像
      。[x] 设置昵称
      。[x] 设置签名
· [x] 设置
      。[x] 个人信息设置
      。[x] 通知提醒
      。[x] 聊天
      。[ ] 隐私(随业务部分一起完善)
      。[ ] 通用(随业务部分一起完善)
      。[ ] 帮助反馈(随业务部分一起完善)
      。[x] 关于
      。[x] 退出
· [ ] 社区
      。[ ] 发布
      。[ ] 评论
      。[ ] 收藏
      。[ ] 关注
发布功能
· [x] 多渠道打包
· [x] 签名配置
· [x] 开发与线上环境配置
· [x] 敏感信息保护
 
  #配置运行
1.首先复制config.default.gradle到config.gradle
2.配置下config.gradle环信appkey以及bugly统计Id
3.正式打包需要配置下签名信息,同时将签名文件放置在项目根目录
 
  #参与贡献
如果你有什么好的想法,或者好的实现,可以通过下边的步骤参与进来,让我们一起把这个项目做得更好,欢迎参与
1.Fork本仓库
2.新建feature_xxx分支 (单独创建一个实现你自己想法的分支)
3.提交代码
4.新建Pull Request
5.等待我们的Review & Merge
 
 #关联项目
服务器端由nodejs实现,地址见这里 VMServer
 
  #VMServer
是为Android开源项目VMMatch项目(中文名猿匹配)实现的服务端
 
  #简介
这个项目包含两部分
· 根目录:服务逻辑及API接口实现
· client目录:前端界面,和服务器端代码端放置在同一仓库下(暂未实现)
 
 #使用
简单介绍下运行环境及部署方法
1.安装nodejs开发时使用的是v10.16.0版本
2.需要安装mongodb并启动,开发使用版本4.0.10
3.下载项目到服务器,可以下载压缩包,或者用git clone命令
4.复制config_default.js到config.js,可根据自己需要修改配置文件
5.安装依赖npm install
6.全局安装pm2npm install pm2 -g 
7.运行 vmshell.sh
 




扫码备注【开源项目】邀你加入环信开源社群
 
转载自https://blog.melove.net/develop-open-source-im-match-and-server/ 
  查看全部
#前言
近期,环信热心开发者-穿裤衩闯天下使用环信IM开发了一款实时聊天应用,包含简单的服务器端,现在正式开源给小伙伴们。感兴趣的同学可以一起搞一下哦,详细介绍请往下看。

猿匹配_logo_副本.png


  上代码
服务器:VMServer
客户端:VMMatch
 
 #VMMatch
猿匹配 —— 国内首个程序猿非严肃婚恋交友应用,让我们一言不合就来场匹配吧
 
#介绍#
首先说下中文名:为什么叫这个名字呢,因为这是一个程序猿(媛)之间匹配交流的应用啊其实这是一个使用环信 IM 开发的一款开源聊天项目,涵盖了时下流行的一些聊天元素,同时已将 IM 功能封装为单独库,可以直接引用,方便使用
项目还处在初期阶段,还有许多功能需要实现,有兴趣的可以一起来
项目资源均来自于互联网,如果有侵权请联系我
 
 #下载体验
猿匹配 小米商店 审核中
猿匹配 Google Play
 
  #项目截图

1.png

2.png

3.png

4.png

5.png

6.png

  
 #开发环境
项目基本属于在最新的Android开发环境下开发,使用Java8的一些新特性,比如Lambda表达式,
然后项目已经适配Android6.x以上的动态权限适配,以及7.x的文件选择,和8.x的通知提醒等;
· Mac OS 10.14.4
· Android Studio 3.3.2
  #项目模块儿
本项目包含两部分:
一部分是项目主模块app,这部分主要包含了项目的业务逻辑,比如匹配、信息修改、设置等
另一部分是封装成library的vmim,这是为了方便大家引用到自己的项目中做的一步封装,不用再去复杂的复制代码和资源等,
只需要将vmim以module导入到自己的项目中就行了,具体使用方式参见项目app模块儿;
 
  #功能与 TODO
IM部分功能
· [x] 链接监听
· [x] 登录注册
· [x] 会话功能
      。[x] 置顶
      。[x] 标为未读
      。[x] 删除与清空
      。[x] 草稿功能
· [x] 消息功能
      。[x] 下拉加载更多
      。[x] 消息复制(仅文字类消息)
      。[x] 消息删除
      。[x] 文本+Emoji消息收发
      。[x] 大表情消息收发
      。[x] 图片消息
        ~[x] 查看大图
        ~[ ] 保存图片
      。[x] 语音消息
        ~[x] 语音录制
        ~[x] 语音播放(可暂停,波形待优化)
        ~[x] 听筒和扬声器播放切换
      。[x] 语音实时通话功能
      。[x] 视频实时通话功能
      。[x] 通话过程中的娱乐消息收发
        ~[x] 骰子
        ~[x] 石头剪刀布
        ~[x] 大表情
      。[x] 昵称头像处理(通过回调实现)
App部分功能
· [x] 登录注册(包括业务逻辑和 IM 逻辑)
· [x] 匹配
      。[x] 提交匹配信息
      。[x] 拉取匹配信息
· [x] 聊天(这里直接加载 IM 模块儿)
· [x] 我的
      。[x] 个人信息展示
      。[x] 上传头像
      。[x] 设置昵称
      。[x] 设置签名
· [x] 设置
      。[x] 个人信息设置
      。[x] 通知提醒
      。[x] 聊天
      。[ ] 隐私(随业务部分一起完善)
      。[ ] 通用(随业务部分一起完善)
      。[ ] 帮助反馈(随业务部分一起完善)
      。[x] 关于
      。[x] 退出
· [ ] 社区
      。[ ] 发布
      。[ ] 评论
      。[ ] 收藏
      。[ ] 关注
发布功能
· [x] 多渠道打包
· [x] 签名配置
· [x] 开发与线上环境配置
· [x] 敏感信息保护
 
  #配置运行
1.首先复制config.default.gradle到config.gradle
2.配置下config.gradle环信appkey以及bugly统计Id
3.正式打包需要配置下签名信息,同时将签名文件放置在项目根目录
 
  #参与贡献
如果你有什么好的想法,或者好的实现,可以通过下边的步骤参与进来,让我们一起把这个项目做得更好,欢迎参与
1.Fork本仓库
2.新建feature_xxx分支 (单独创建一个实现你自己想法的分支)
3.提交代码
4.新建Pull Request
5.等待我们的Review & Merge
 
 #关联项目
服务器端由nodejs实现,地址见这里 VMServer
 
  #VMServer
是为Android开源项目VMMatch项目(中文名猿匹配)实现的服务端
 
  #简介
这个项目包含两部分
· 根目录:服务逻辑及API接口实现
· client目录:前端界面,和服务器端代码端放置在同一仓库下(暂未实现)
 
 #使用
简单介绍下运行环境及部署方法
1.安装nodejs开发时使用的是v10.16.0版本
2.需要安装mongodb并启动,开发使用版本4.0.10
3.下载项目到服务器,可以下载压缩包,或者用git clone命令
4.复制config_default.js到config.js,可根据自己需要修改配置文件
5.安装依赖
npm install

6.全局安装pm2
npm install pm2 -g
 
7.运行 vmshell.sh
 
环信冬冬_副本.jpg

扫码备注【开源项目】邀你加入环信开源社群
 
转载自https://blog.melove.net/develop-open-source-im-match-and-server/ 
 
4
评论

在微信小程序里实现聊天室 聊天室 小程序

Tolazy 发表了文章 • 40640 次浏览 • 2019-04-19 17:49 • 来自相关话题

第一次搞小程序,老板让我实现一个聊天室功能,压力山大啊。
花了几天时间研究比较了一下方案,最后基于环信的小程序SDK 开发了一个聊天室。
 
准备工作
下载环信 小程序demo+sdkgit clone https://github.com/easemob/webim-weixin-xcx创建一个文件夹,将 demo 中的文件 comps、images、sdk、utils 拷贝到新的文件,文件目录说明



集成
登录环信没什么可说的,这里选择的是使用 username/password 登录,和demo中的一样,文件没有进行任何更改


在app.js 中注册的 WebIM.conn.listen, 然后在 登陆成功的回调 onOpened 设置的跳转页面,并将登陆的 username 赋给 myName,传到新的页面中使用


修改 roomlist.js 获取聊天室列表,是分页获取的,这里先偷个懒,获取了第一页 20 个聊天室


然后将listChatrooms() 分别在onLoad、onShow 内,更改下,将原有的 listGroups() 替换掉然后在roomlist.wxml 修改对应的 变量绑定名称





demo中的group.js 中,获取到的是当前登陆账号已加入的群组,咱们做的是聊天室功能,所以需要有一个加入的操作,找roomlist.js 中找到 into_room: function (event),然后填写加入聊天室的方法, 我是直接在当前这个里面加的跳转到聊天页面,并将当前登陆的IDmyName,聊天室IDgroupID,聊天室名称your 传给新页面


Ex:监听是否加入聊天室成功的回调是在 onPresence 中,type:memberJoinChatRoomSuccess,正常是监听这个回调跳转页面,有点麻烦就直接这样吧到会话页面后,需要修改一下对应的消息格式,在comps/chat/suit 目录下,将里面的文件对应的 js 文件根据文档给聊天室发送消息 格式进行修改,聊天室消息和群组消息不同,所以我目前是直接将getSendToParam()、isGroupChat() 注释,改成下面这样,demo 中下面还有代码的,这里就用 …… 代替了





就这样了,简单集成聊天室功能,demo中的UI 是开源的,可以根据自己的需求更改~下面是具体实现过程。代码也放在github 上了,有需要的兄弟自取。demo下载地址:https://github.com/lizgDonkey/room-xcx 查看全部
第一次搞小程序,老板让我实现一个聊天室功能,压力山大啊。
花了几天时间研究比较了一下方案,最后基于环信的小程序SDK 开发了一个聊天室。
 
准备工作
  1. 下载环信 小程序demo+sdk
    git clone https://github.com/easemob/webim-weixin-xcx
  2. 创建一个文件夹,将 demo 中的文件 comps、images、sdk、utils 拷贝到新的文件,文件目录说明
    ml.png

集成
  1. 登录环信没什么可说的,这里选择的是使用 username/password 登录,和demo中的一样,文件没有进行任何更改
    login.png
  2. 在app.js 中注册的 WebIM.conn.listen, 然后在 登陆成功的回调 onOpened 设置的跳转页面,并将登陆的 username 赋给 myName,传到新的页面中使用
    tz.png
  3. 修改 roomlist.js 获取聊天室列表,是分页获取的,这里先偷个懒,获取了第一页 20 个聊天室
    getroom.png
    然后将listChatrooms() 分别在onLoad、onShow 内,更改下,将原有的 listGroups() 替换掉
  4. 然后在roomlist.wxml 修改对应的 变量绑定名称
    listui.png
    list.png
  5. demo中的group.js 中,获取到的是当前登陆账号已加入的群组,咱们做的是聊天室功能,所以需要有一个加入的操作,找roomlist.js 中找到 into_room: function (event),然后填写加入聊天室的方法, 我是直接在当前这个里面加的跳转到聊天页面,并将当前登陆的IDmyName,聊天室IDgroupID,聊天室名称your 传给新页面
    joinrom.png
    Ex:监听是否加入聊天室成功的回调是在 onPresence 中,type:memberJoinChatRoomSuccess,正常是监听这个回调跳转页面,有点麻烦就直接这样吧
  6. 到会话页面后,需要修改一下对应的消息格式,在comps/chat/suit 目录下,将里面的文件对应的 js 文件根据文档给聊天室发送消息 格式进行修改,聊天室消息和群组消息不同,所以我目前是直接将getSendToParam()、isGroupChat() 注释,改成下面这样,demo 中下面还有代码的,这里就用 …… 代替了
    send.png
    chat.png
    就这样了,简单集成聊天室功能,demo中的UI 是开源的,可以根据自己的需求更改~下面是具体实现过程。代码也放在github 上了,有需要的兄弟自取。demo下载地址:https://github.com/lizgDonkey/room-xcx

4
评论

【开源项目】全国首个开源直播小程序源码

beyond 发表了文章 • 182789 次浏览 • 2018-07-20 17:30 • 来自相关话题

今天你看直播了吗?拥有10亿微信生态用户的小程序已经成为了继移动互联后的又一个现象级风口,随着微信小程序对外开放实时音视频录制及播放等更多连接能力,小程序与直播强强联合,在各行各业找到了非常多的玩法,小程序直播相比微信直播和APP直播更加简洁、流畅、低延时、多入口等众多优势迅速向商业直播领域及泛娱乐直播领域蔓延。从小游戏、内容付费、工具、大数据、社交电商创业者到传统品牌商们,都在努力搭上小程序直播这辆快车,以免错过微信生态里新的流量洼地。
 





作为一名环信生态圈资深开发者,本着对技术的热衷,对环信的眷恋和对党的忠诚,基于环信即时通讯云写了“直播购物小程序”,目前项目源码已全部免费开放,希望对有需求的企业和开发者提供一个思路和参考。
直播购物小程序源码github地址:https://github.com/YuTongNetworkTechnology/wechat_live/tree/master 
git打不开可直接点下面链接下载


小程序直播demo_2018-06-21.zip







直播购物小程序运行预览图 
 
小程序体验指南(仅需两步):
 
1、下载微信小程序开发工具,下载地址:https://developers.weixin.qq.c ... .html 
 




2、导入源码:将附件的源码解压直接导入 







环信小程序直播技术文档
一、 使用的技术
1、 环信IM直播室。
2、 微信小程序实时音视频播放组件live-player。
3、 推流软件(obs、易推流)等推流。
4、 视频流服务器(UCLOUD、七牛、腾讯)等视频流服务器。
二、 系统使用流程。
1、 视频推流软件将视频流推到流服务器。
2、 打开视频直播demo小程序注册环信账号。
3、 进入软件直播室进行测试。
三、 技术流程及使用的SDk
1、 注册环信账号
打开https://www.easemob.com/ 环信官网,点击右上角注册按钮,选择[注册即时通讯云]




填写对相关信息进行注册





注册成功后进行登录




注:新注册用户需进行账号的认证。
2、 直播应用创建
登录成功点击应用列表选择创建应用




输入应用名称等信息
 





创建成功后点击应用进入





需要注意的是应用的OrgName 和AppName这两个是以后都需要用到的两个参数变量




3、 直播创建
1)在创建直播之前需要对应用进行设置首先需要设置应用的直播流地址
第一步获取应用管理员的Tokencurl -X POST "https://a1.easemob.com/[应用OrgName]/[应用AppName]/token" -d '{"grant_type":"client_credentials","client_id":"[应用client_id]","client_secret":"[应用] client_secret"}'返回格式{
"access_token":"YWMtWY779DgJEeS2h9OR7fw4QgAAAUmO4Qukwd9cfJSpkWHiOa7MCSk0MrkVIco",
"expires_in":5184000,
"application":"c03b3e30-046a-11e4-8ed1-5701cdaaa0e4"












第二步设置直播流地址curl -X POST -H "Authorization: Bearer [管理员Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms/stream_url -d '{"pc_pull":"[pc拉流地址]","pc_push":"[pc推流地址]","mobile_pull":"[手机拉流地址]","mobile_push":"[手机推流地址]"}'"成功返回格式:{
"action": "post",
"application": "e1a09de0-0e03-11e7-ad8e-a1d913615409",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"pc_pull": true,
"mobile_push": true,
"mobile_pull": true,
"pc_push": true
},
"timestamp": 1494084474885,
"duration": 1,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












2)创建主播
点击IM用户





点击注册IM用户





填写用户信息





创建用户的过程同样也可以通过REST API形式进行curl -X POST -i " https://a1.easemob.com/[应用OrgName]/[应用AppName]/users" -d '{"username":"[用户名]","password":"[密码]"}'
注:应用必须为开放注册





将注册的用户添加为主播curl -X POST -H "Authorization: [管理员Token]" https://a1.easemob.com/[应用OrgName]/[应用AppName]/super_admin -d'{"superadmin":"[IM用户名]"}'返回结果示例:{
"action": "post",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"result": "success"
},
"timestamp": 1496236798886,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












3)创建直播
点击直播





点击新建房间





填写房间信息




创建房间同时也可以使用REST API形式进行详情可以查看http://docs.easemob.com/im/live/server-integration环信官方文档。
4、 小程序demo集成使用
小程序直播购物demo集成官方WebIM SDK详情请查看https://github.com/easemob/webim-weixin-xcx
Demo具体配置如下
打开demo 下sdk配置文件





修改appkey为自己应用的appkey





打开pages/live/index.js修改房间默认拉流地址及直播间房间号





四、 扩展说明
Demo中房间为固定测试房间,实际使用中应获取环信直播的房间信息及房间列表。具体如下:
获取直播间列表:curl -X GET -H "Authorization: Bearer [用户Token]" https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms?ongoing=true&limit=[获取数量]&cursor=[游标地址(不填写为充开始查询)]
响应:{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"params": {
"cursor": [
"ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6MzE"
],
"ongoing": [
"true"
],
"limit": [
"2"
]
},
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": [
{
"id": "1924",
"chatroom_id": "17177265635330",
"title": "具体了",
"desc": "就咯",
"startTime": 1495779917352,
"endTime": 1495779917352,
"anchor": "wuls",
"gift_count": 0,
"praise_count": 0,
"current_user_count": 8,
"max_user_count": 9,
"status": "ongoing",
"cover_picture_url": "",
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1"
},
{
"id": "1922",
"chatroom_id": "17175003856897",
"title": "香山",
"desc": "随便",
"startTime": 1495777760957,
"endTime": 1495777760957,
"anchor": "sx001",
"gift_count": 0,
"praise_count": 8,
"current_user_count": 1,
"max_user_count": 3,
"status": "ongoing",
"cover_picture_url": "http://127.0.0.1:8080/easemob- ... ot%3B,
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1"
}
],
"timestamp": 1496303336669,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"cursor": "ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6NDk",
"count": 2
}












获取直播间详情:curl -X GET -H "Authorization: Bearer [用户Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/[房间id]/status"响应:{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"liveRoomID": "1946",
"status": "ongoing"
},
"timestamp": 1496234759930,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"count": 0
}














 
使用环信直播购物小程序遇到任何问题欢迎跟帖讨论。 查看全部
今天你看直播了吗?
拥有10亿微信生态用户的小程序已经成为了继移动互联后的又一个现象级风口,随着微信小程序对外开放实时音视频录制及播放等更多连接能力,小程序与直播强强联合,在各行各业找到了非常多的玩法,小程序直播相比微信直播和APP直播更加简洁、流畅、低延时、多入口等众多优势迅速向商业直播领域及泛娱乐直播领域蔓延。从小游戏、内容付费、工具、大数据、社交电商创业者到传统品牌商们,都在努力搭上小程序直播这辆快车,以免错过微信生态里新的流量洼地。
 
微信图片_20180725162426.jpg


作为一名环信生态圈资深开发者,本着对技术的热衷,对环信的眷恋和对党的忠诚,基于环信即时通讯云写了“直播购物小程序”,目前项目源码已全部免费开放,希望对有需求的企业和开发者提供一个思路和参考。
直播购物小程序源码github地址:https://github.com/YuTongNetworkTechnology/wechat_live/tree/master 
git打不开可直接点下面链接下载



预览图.jpg

直播购物小程序运行预览图 
 
小程序体验指南(仅需两步):
 
1、下载微信小程序开发工具,下载地址:https://developers.weixin.qq.c ... .html 
 
Catch9A07(07-20-17-38-30).jpg

2、导入源码:将附件的源码解压直接导入 


Catch1C69(07-20-17-38-30).jpg


环信小程序直播技术文档
一、 使用的技术
1、 环信IM直播室。
2、 微信小程序实时音视频播放组件live-player。
3、 推流软件(obs、易推流)等推流。
4、 视频流服务器(UCLOUD、七牛、腾讯)等视频流服务器。
二、 系统使用流程。
1、 视频推流软件将视频流推到流服务器。
2、 打开视频直播demo小程序注册环信账号。
3、 进入软件直播室进行测试。
三、 技术流程及使用的SDk
1、 注册环信账号
打开https://www.easemob.com/ 环信官网,点击右上角注册按钮,选择[注册即时通讯云]
1.png

填写对相关信息进行注册

2.png

注册成功后进行登录
3.png

注:新注册用户需进行账号的认证。
2、 直播应用创建
登录成功点击应用列表选择创建应用
4.png

输入应用名称等信息
 

5.png

创建成功后点击应用进入

6.png

需要注意的是应用的OrgName 和AppName这两个是以后都需要用到的两个参数变量
7.png

3、 直播创建
1)在创建直播之前需要对应用进行设置首先需要设置应用的直播流地址
第一步获取应用管理员的Token
curl -X POST "https://a1.easemob.com/[应用OrgName]/[应用AppName]/token" -d '{"grant_type":"client_credentials","client_id":"[应用client_id]","client_secret":"[应用] client_secret"}'
返回格式
{
"access_token":"YWMtWY779DgJEeS2h9OR7fw4QgAAAUmO4Qukwd9cfJSpkWHiOa7MCSk0MrkVIco",
"expires_in":5184000,
"application":"c03b3e30-046a-11e4-8ed1-5701cdaaa0e4"












第二步设置直播流地址
curl -X POST -H "Authorization: Bearer [管理员Token]"  " https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms/stream_url -d '{"pc_pull":"[pc拉流地址]","pc_push":"[pc推流地址]","mobile_pull":"[手机拉流地址]","mobile_push":"[手机推流地址]"}'"
成功返回格式:
{
"action": "post",
"application": "e1a09de0-0e03-11e7-ad8e-a1d913615409",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"pc_pull": true,
"mobile_push": true,
"mobile_pull": true,
"pc_push": true
},
"timestamp": 1494084474885,
"duration": 1,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












2)创建主播
点击IM用户

8.png

点击注册IM用户

9.png

填写用户信息

10.png

创建用户的过程同样也可以通过REST API形式进行
curl -X POST -i " https://a1.easemob.com/[应用OrgName]/[应用AppName]/users" -d '{"username":"[用户名]","password":"[密码]"}'

注:应用必须为开放注册

11.png

将注册的用户添加为主播
curl -X POST -H "Authorization: [管理员Token]"  https://a1.easemob.com/[应用OrgName]/[应用AppName]/super_admin -d'{"superadmin":"[IM用户名]"}'
返回结果示例:
{
"action": "post",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"result": "success"
},
"timestamp": 1496236798886,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












3)创建直播
点击直播

12.png

点击新建房间

13.png

填写房间信息
14.png

创建房间同时也可以使用REST API形式进行详情可以查看http://docs.easemob.com/im/live/server-integration环信官方文档。
4、 小程序demo集成使用
小程序直播购物demo集成官方WebIM SDK详情请查看https://github.com/easemob/webim-weixin-xcx
Demo具体配置如下
打开demo 下sdk配置文件

15.png

修改appkey为自己应用的appkey

16.png

打开pages/live/index.js修改房间默认拉流地址及直播间房间号

17.png

四、 扩展说明
Demo中房间为固定测试房间,实际使用中应获取环信直播的房间信息及房间列表。具体如下:
获取直播间列表:
curl -X GET -H "Authorization: Bearer  [用户Token]"  https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms?ongoing=true&limit=[获取数量]&cursor=[游标地址(不填写为充开始查询)]

响应:
{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"params": {
"cursor": [
"ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6MzE"
],
"ongoing": [
"true"
],
"limit": [
"2"
]
},
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": [
{
"id": "1924",
"chatroom_id": "17177265635330",
"title": "具体了",
"desc": "就咯",
"startTime": 1495779917352,
"endTime": 1495779917352,
"anchor": "wuls",
"gift_count": 0,
"praise_count": 0,
"current_user_count": 8,
"max_user_count": 9,
"status": "ongoing",
"cover_picture_url": "",
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1"
},
{
"id": "1922",
"chatroom_id": "17175003856897",
"title": "香山",
"desc": "随便",
"startTime": 1495777760957,
"endTime": 1495777760957,
"anchor": "sx001",
"gift_count": 0,
"praise_count": 8,
"current_user_count": 1,
"max_user_count": 3,
"status": "ongoing",
"cover_picture_url": "http://127.0.0.1:8080/easemob- ... ot%3B,
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1"
}
],
"timestamp": 1496303336669,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"cursor": "ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6NDk",
"count": 2
}












获取直播间详情:
curl -X GET -H "Authorization: Bearer [用户Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/[房间id]/status"
响应:
{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"liveRoomID": "1946",
"status": "ongoing"
},
"timestamp": 1496234759930,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"count": 0
}














 
使用环信直播购物小程序遇到任何问题欢迎跟帖讨论。
19
评论

【新手快速入门】集成环信常见问题+解决方案汇总

dujiepeng 发表了文章 • 26106 次浏览 • 2017-05-22 15:51 • 来自相关话题

   这里整理了集成环信的常见问题和一些功能的实现思路,希望能帮助到大家。感谢热心的开发者贡献,大家在观看过程中有不明白的地方欢迎直接跟帖咨询。
 
ios篇
APNs证书创建和上传到环信后台头像昵称的简述和处理方案音视频离线推送Demo实现环信服务器聊天记录保存多久?离线收不到好友请求IOS中环信聊天窗口如何实现文件发送和预览的功能ios集成常见问题环信推送的一些常见问题实现名片|红包|话题聊天室等自定义cell
 
Android篇
Android sdk 的两种导入方式环信3.0SDK集成小米推送教程EaseUI库中V4、v7包冲突解决方案Android EaseUI里的百度地图替换为高德地图android扩展消息(名片集成)关于会话列表的置顶聊天java.lang.UnsatisfiedLinkError: 的问题android 端 app 后台被杀死收不到消息的解决方案
昵称头像篇
android中如何显示开发者服务器上的昵称和头像 Android中显示头像(接上一篇文章看)环信(Android)设置头像和昵称的方法(最简单暴力的基于环信demo的集成)IOS中如何显示开发者服务器上的昵称和头像【环信公开课第12期视频回放】-所有关于环信IM昵称头像的问题听这课就够了
 
直播篇
一言不合你就搞个直播APP
 
客服集成
IM-SDK和客服SDK并存开发指南—Android篇IM-SDK和客服SDK并存开发指南—iOS篇
 
开源项目
Android简版demoios简版demo凡信2.0:超仿微信的开源项目 凡信3.0:携直播和红包而来高仿微信:Github 3,515 Star方圆十里:环信编程大赛冠军项目泛聊:定一个小目标写一个QQSlack聊天机器人:一天时间做一个聊天机器人TV视频通话:在电视上视频通话视频通话:Android手机视频通话酷信:ios高仿微信公众号助手:与订阅用户聊天沟通
 
持续更新ing...小伙伴们还有什么想知道欢迎跟帖提出。
  查看全部
   这里整理了集成环信的常见问题和一些功能的实现思路,希望能帮助到大家。感谢热心的开发者贡献,大家在观看过程中有不明白的地方欢迎直接跟帖咨询。
 
ios篇

 
Android篇

昵称头像篇

 
直播篇
  1. 一言不合你就搞个直播APP

 
客服集成
  1. IM-SDK和客服SDK并存开发指南—Android篇
  2. IM-SDK和客服SDK并存开发指南—iOS篇

 
开源项目

 
持续更新ing...小伙伴们还有什么想知道欢迎跟帖提出。
 
8
评论

【源码下载】一款使用环信实现的开源灵魂社交APP(含服务器) 猿匹配 开源

beyond 发表了文章 • 13077 次浏览 • 2019-07-01 10:48 • 来自相关话题

#前言
近期,环信热心开发者-穿裤衩闯天下使用环信IM开发了一款实时聊天应用,包含简单的服务器端,现在正式开源给小伙伴们。感兴趣的同学可以一起搞一下哦,详细介绍请往下看。






  上代码
服务器:VMServer
客户端:VMMatch
 
 #VMMatch
猿匹配 —— 国内首个程序猿非严肃婚恋交友应用,让我们一言不合就来场匹配吧
 
#介绍#
首先说下中文名:为什么叫这个名字呢,因为这是一个程序猿(媛)之间匹配交流的应用啊其实这是一个使用环信 IM 开发的一款开源聊天项目,涵盖了时下流行的一些聊天元素,同时已将 IM 功能封装为单独库,可以直接引用,方便使用
项目还处在初期阶段,还有许多功能需要实现,有兴趣的可以一起来
项目资源均来自于互联网,如果有侵权请联系我
 
 #下载体验
猿匹配 小米商店 审核中
猿匹配 Google Play
 
  #项目截图

























  
 #开发环境
项目基本属于在最新的Android开发环境下开发,使用Java8的一些新特性,比如Lambda表达式,
然后项目已经适配Android6.x以上的动态权限适配,以及7.x的文件选择,和8.x的通知提醒等;
· Mac OS 10.14.4
· Android Studio 3.3.2
  #项目模块儿
本项目包含两部分:
一部分是项目主模块app,这部分主要包含了项目的业务逻辑,比如匹配、信息修改、设置等
另一部分是封装成library的vmim,这是为了方便大家引用到自己的项目中做的一步封装,不用再去复杂的复制代码和资源等,
只需要将vmim以module导入到自己的项目中就行了,具体使用方式参见项目app模块儿;
 
  #功能与 TODO
IM部分功能
· [x] 链接监听
· [x] 登录注册
· [x] 会话功能
      。[x] 置顶
      。[x] 标为未读
      。[x] 删除与清空
      。[x] 草稿功能
· [x] 消息功能
      。[x] 下拉加载更多
      。[x] 消息复制(仅文字类消息)
      。[x] 消息删除
      。[x] 文本+Emoji消息收发
      。[x] 大表情消息收发
      。[x] 图片消息
        ~[x] 查看大图
        ~[ ] 保存图片
      。[x] 语音消息
        ~[x] 语音录制
        ~[x] 语音播放(可暂停,波形待优化)
        ~[x] 听筒和扬声器播放切换
      。[x] 语音实时通话功能
      。[x] 视频实时通话功能
      。[x] 通话过程中的娱乐消息收发
        ~[x] 骰子
        ~[x] 石头剪刀布
        ~[x] 大表情
      。[x] 昵称头像处理(通过回调实现)
App部分功能
· [x] 登录注册(包括业务逻辑和 IM 逻辑)
· [x] 匹配
      。[x] 提交匹配信息
      。[x] 拉取匹配信息
· [x] 聊天(这里直接加载 IM 模块儿)
· [x] 我的
      。[x] 个人信息展示
      。[x] 上传头像
      。[x] 设置昵称
      。[x] 设置签名
· [x] 设置
      。[x] 个人信息设置
      。[x] 通知提醒
      。[x] 聊天
      。[ ] 隐私(随业务部分一起完善)
      。[ ] 通用(随业务部分一起完善)
      。[ ] 帮助反馈(随业务部分一起完善)
      。[x] 关于
      。[x] 退出
· [ ] 社区
      。[ ] 发布
      。[ ] 评论
      。[ ] 收藏
      。[ ] 关注
发布功能
· [x] 多渠道打包
· [x] 签名配置
· [x] 开发与线上环境配置
· [x] 敏感信息保护
 
  #配置运行
1.首先复制config.default.gradle到config.gradle
2.配置下config.gradle环信appkey以及bugly统计Id
3.正式打包需要配置下签名信息,同时将签名文件放置在项目根目录
 
  #参与贡献
如果你有什么好的想法,或者好的实现,可以通过下边的步骤参与进来,让我们一起把这个项目做得更好,欢迎参与
1.Fork本仓库
2.新建feature_xxx分支 (单独创建一个实现你自己想法的分支)
3.提交代码
4.新建Pull Request
5.等待我们的Review & Merge
 
 #关联项目
服务器端由nodejs实现,地址见这里 VMServer
 
  #VMServer
是为Android开源项目VMMatch项目(中文名猿匹配)实现的服务端
 
  #简介
这个项目包含两部分
· 根目录:服务逻辑及API接口实现
· client目录:前端界面,和服务器端代码端放置在同一仓库下(暂未实现)
 
 #使用
简单介绍下运行环境及部署方法
1.安装nodejs开发时使用的是v10.16.0版本
2.需要安装mongodb并启动,开发使用版本4.0.10
3.下载项目到服务器,可以下载压缩包,或者用git clone命令
4.复制config_default.js到config.js,可根据自己需要修改配置文件
5.安装依赖npm install
6.全局安装pm2npm install pm2 -g 
7.运行 vmshell.sh
 




扫码备注【开源项目】邀你加入环信开源社群
 
转载自https://blog.melove.net/develop-open-source-im-match-and-server/ 
  查看全部
#前言
近期,环信热心开发者-穿裤衩闯天下使用环信IM开发了一款实时聊天应用,包含简单的服务器端,现在正式开源给小伙伴们。感兴趣的同学可以一起搞一下哦,详细介绍请往下看。

猿匹配_logo_副本.png


  上代码
服务器:VMServer
客户端:VMMatch
 
 #VMMatch
猿匹配 —— 国内首个程序猿非严肃婚恋交友应用,让我们一言不合就来场匹配吧
 
#介绍#
首先说下中文名:为什么叫这个名字呢,因为这是一个程序猿(媛)之间匹配交流的应用啊其实这是一个使用环信 IM 开发的一款开源聊天项目,涵盖了时下流行的一些聊天元素,同时已将 IM 功能封装为单独库,可以直接引用,方便使用
项目还处在初期阶段,还有许多功能需要实现,有兴趣的可以一起来
项目资源均来自于互联网,如果有侵权请联系我
 
 #下载体验
猿匹配 小米商店 审核中
猿匹配 Google Play
 
  #项目截图

1.png

2.png

3.png

4.png

5.png

6.png

  
 #开发环境
项目基本属于在最新的Android开发环境下开发,使用Java8的一些新特性,比如Lambda表达式,
然后项目已经适配Android6.x以上的动态权限适配,以及7.x的文件选择,和8.x的通知提醒等;
· Mac OS 10.14.4
· Android Studio 3.3.2
  #项目模块儿
本项目包含两部分:
一部分是项目主模块app,这部分主要包含了项目的业务逻辑,比如匹配、信息修改、设置等
另一部分是封装成library的vmim,这是为了方便大家引用到自己的项目中做的一步封装,不用再去复杂的复制代码和资源等,
只需要将vmim以module导入到自己的项目中就行了,具体使用方式参见项目app模块儿;
 
  #功能与 TODO
IM部分功能
· [x] 链接监听
· [x] 登录注册
· [x] 会话功能
      。[x] 置顶
      。[x] 标为未读
      。[x] 删除与清空
      。[x] 草稿功能
· [x] 消息功能
      。[x] 下拉加载更多
      。[x] 消息复制(仅文字类消息)
      。[x] 消息删除
      。[x] 文本+Emoji消息收发
      。[x] 大表情消息收发
      。[x] 图片消息
        ~[x] 查看大图
        ~[ ] 保存图片
      。[x] 语音消息
        ~[x] 语音录制
        ~[x] 语音播放(可暂停,波形待优化)
        ~[x] 听筒和扬声器播放切换
      。[x] 语音实时通话功能
      。[x] 视频实时通话功能
      。[x] 通话过程中的娱乐消息收发
        ~[x] 骰子
        ~[x] 石头剪刀布
        ~[x] 大表情
      。[x] 昵称头像处理(通过回调实现)
App部分功能
· [x] 登录注册(包括业务逻辑和 IM 逻辑)
· [x] 匹配
      。[x] 提交匹配信息
      。[x] 拉取匹配信息
· [x] 聊天(这里直接加载 IM 模块儿)
· [x] 我的
      。[x] 个人信息展示
      。[x] 上传头像
      。[x] 设置昵称
      。[x] 设置签名
· [x] 设置
      。[x] 个人信息设置
      。[x] 通知提醒
      。[x] 聊天
      。[ ] 隐私(随业务部分一起完善)
      。[ ] 通用(随业务部分一起完善)
      。[ ] 帮助反馈(随业务部分一起完善)
      。[x] 关于
      。[x] 退出
· [ ] 社区
      。[ ] 发布
      。[ ] 评论
      。[ ] 收藏
      。[ ] 关注
发布功能
· [x] 多渠道打包
· [x] 签名配置
· [x] 开发与线上环境配置
· [x] 敏感信息保护
 
  #配置运行
1.首先复制config.default.gradle到config.gradle
2.配置下config.gradle环信appkey以及bugly统计Id
3.正式打包需要配置下签名信息,同时将签名文件放置在项目根目录
 
  #参与贡献
如果你有什么好的想法,或者好的实现,可以通过下边的步骤参与进来,让我们一起把这个项目做得更好,欢迎参与
1.Fork本仓库
2.新建feature_xxx分支 (单独创建一个实现你自己想法的分支)
3.提交代码
4.新建Pull Request
5.等待我们的Review & Merge
 
 #关联项目
服务器端由nodejs实现,地址见这里 VMServer
 
  #VMServer
是为Android开源项目VMMatch项目(中文名猿匹配)实现的服务端
 
  #简介
这个项目包含两部分
· 根目录:服务逻辑及API接口实现
· client目录:前端界面,和服务器端代码端放置在同一仓库下(暂未实现)
 
 #使用
简单介绍下运行环境及部署方法
1.安装nodejs开发时使用的是v10.16.0版本
2.需要安装mongodb并启动,开发使用版本4.0.10
3.下载项目到服务器,可以下载压缩包,或者用git clone命令
4.复制config_default.js到config.js,可根据自己需要修改配置文件
5.安装依赖
npm install

6.全局安装pm2
npm install pm2 -g
 
7.运行 vmshell.sh
 
环信冬冬_副本.jpg

扫码备注【开源项目】邀你加入环信开源社群
 
转载自https://blog.melove.net/develop-open-source-im-match-and-server/ 
 
4
评论

在微信小程序里实现聊天室 聊天室 小程序

Tolazy 发表了文章 • 40640 次浏览 • 2019-04-19 17:49 • 来自相关话题

第一次搞小程序,老板让我实现一个聊天室功能,压力山大啊。
花了几天时间研究比较了一下方案,最后基于环信的小程序SDK 开发了一个聊天室。
 
准备工作
下载环信 小程序demo+sdkgit clone https://github.com/easemob/webim-weixin-xcx创建一个文件夹,将 demo 中的文件 comps、images、sdk、utils 拷贝到新的文件,文件目录说明



集成
登录环信没什么可说的,这里选择的是使用 username/password 登录,和demo中的一样,文件没有进行任何更改


在app.js 中注册的 WebIM.conn.listen, 然后在 登陆成功的回调 onOpened 设置的跳转页面,并将登陆的 username 赋给 myName,传到新的页面中使用


修改 roomlist.js 获取聊天室列表,是分页获取的,这里先偷个懒,获取了第一页 20 个聊天室


然后将listChatrooms() 分别在onLoad、onShow 内,更改下,将原有的 listGroups() 替换掉然后在roomlist.wxml 修改对应的 变量绑定名称





demo中的group.js 中,获取到的是当前登陆账号已加入的群组,咱们做的是聊天室功能,所以需要有一个加入的操作,找roomlist.js 中找到 into_room: function (event),然后填写加入聊天室的方法, 我是直接在当前这个里面加的跳转到聊天页面,并将当前登陆的IDmyName,聊天室IDgroupID,聊天室名称your 传给新页面


Ex:监听是否加入聊天室成功的回调是在 onPresence 中,type:memberJoinChatRoomSuccess,正常是监听这个回调跳转页面,有点麻烦就直接这样吧到会话页面后,需要修改一下对应的消息格式,在comps/chat/suit 目录下,将里面的文件对应的 js 文件根据文档给聊天室发送消息 格式进行修改,聊天室消息和群组消息不同,所以我目前是直接将getSendToParam()、isGroupChat() 注释,改成下面这样,demo 中下面还有代码的,这里就用 …… 代替了





就这样了,简单集成聊天室功能,demo中的UI 是开源的,可以根据自己的需求更改~下面是具体实现过程。代码也放在github 上了,有需要的兄弟自取。demo下载地址:https://github.com/lizgDonkey/room-xcx 查看全部
第一次搞小程序,老板让我实现一个聊天室功能,压力山大啊。
花了几天时间研究比较了一下方案,最后基于环信的小程序SDK 开发了一个聊天室。
 
准备工作
  1. 下载环信 小程序demo+sdk
    git clone https://github.com/easemob/webim-weixin-xcx
  2. 创建一个文件夹,将 demo 中的文件 comps、images、sdk、utils 拷贝到新的文件,文件目录说明
    ml.png

集成
  1. 登录环信没什么可说的,这里选择的是使用 username/password 登录,和demo中的一样,文件没有进行任何更改
    login.png
  2. 在app.js 中注册的 WebIM.conn.listen, 然后在 登陆成功的回调 onOpened 设置的跳转页面,并将登陆的 username 赋给 myName,传到新的页面中使用
    tz.png
  3. 修改 roomlist.js 获取聊天室列表,是分页获取的,这里先偷个懒,获取了第一页 20 个聊天室
    getroom.png
    然后将listChatrooms() 分别在onLoad、onShow 内,更改下,将原有的 listGroups() 替换掉
  4. 然后在roomlist.wxml 修改对应的 变量绑定名称
    listui.png
    list.png
  5. demo中的group.js 中,获取到的是当前登陆账号已加入的群组,咱们做的是聊天室功能,所以需要有一个加入的操作,找roomlist.js 中找到 into_room: function (event),然后填写加入聊天室的方法, 我是直接在当前这个里面加的跳转到聊天页面,并将当前登陆的IDmyName,聊天室IDgroupID,聊天室名称your 传给新页面
    joinrom.png
    Ex:监听是否加入聊天室成功的回调是在 onPresence 中,type:memberJoinChatRoomSuccess,正常是监听这个回调跳转页面,有点麻烦就直接这样吧
  6. 到会话页面后,需要修改一下对应的消息格式,在comps/chat/suit 目录下,将里面的文件对应的 js 文件根据文档给聊天室发送消息 格式进行修改,聊天室消息和群组消息不同,所以我目前是直接将getSendToParam()、isGroupChat() 注释,改成下面这样,demo 中下面还有代码的,这里就用 …… 代替了
    send.png
    chat.png
    就这样了,简单集成聊天室功能,demo中的UI 是开源的,可以根据自己的需求更改~下面是具体实现过程。代码也放在github 上了,有需要的兄弟自取。demo下载地址:https://github.com/lizgDonkey/room-xcx

4
评论

【开源项目】全国首个开源直播小程序源码

beyond 发表了文章 • 182789 次浏览 • 2018-07-20 17:30 • 来自相关话题

今天你看直播了吗?拥有10亿微信生态用户的小程序已经成为了继移动互联后的又一个现象级风口,随着微信小程序对外开放实时音视频录制及播放等更多连接能力,小程序与直播强强联合,在各行各业找到了非常多的玩法,小程序直播相比微信直播和APP直播更加简洁、流畅、低延时、多入口等众多优势迅速向商业直播领域及泛娱乐直播领域蔓延。从小游戏、内容付费、工具、大数据、社交电商创业者到传统品牌商们,都在努力搭上小程序直播这辆快车,以免错过微信生态里新的流量洼地。
 





作为一名环信生态圈资深开发者,本着对技术的热衷,对环信的眷恋和对党的忠诚,基于环信即时通讯云写了“直播购物小程序”,目前项目源码已全部免费开放,希望对有需求的企业和开发者提供一个思路和参考。
直播购物小程序源码github地址:https://github.com/YuTongNetworkTechnology/wechat_live/tree/master 
git打不开可直接点下面链接下载


小程序直播demo_2018-06-21.zip







直播购物小程序运行预览图 
 
小程序体验指南(仅需两步):
 
1、下载微信小程序开发工具,下载地址:https://developers.weixin.qq.c ... .html 
 




2、导入源码:将附件的源码解压直接导入 







环信小程序直播技术文档
一、 使用的技术
1、 环信IM直播室。
2、 微信小程序实时音视频播放组件live-player。
3、 推流软件(obs、易推流)等推流。
4、 视频流服务器(UCLOUD、七牛、腾讯)等视频流服务器。
二、 系统使用流程。
1、 视频推流软件将视频流推到流服务器。
2、 打开视频直播demo小程序注册环信账号。
3、 进入软件直播室进行测试。
三、 技术流程及使用的SDk
1、 注册环信账号
打开https://www.easemob.com/ 环信官网,点击右上角注册按钮,选择[注册即时通讯云]




填写对相关信息进行注册





注册成功后进行登录




注:新注册用户需进行账号的认证。
2、 直播应用创建
登录成功点击应用列表选择创建应用




输入应用名称等信息
 





创建成功后点击应用进入





需要注意的是应用的OrgName 和AppName这两个是以后都需要用到的两个参数变量




3、 直播创建
1)在创建直播之前需要对应用进行设置首先需要设置应用的直播流地址
第一步获取应用管理员的Tokencurl -X POST "https://a1.easemob.com/[应用OrgName]/[应用AppName]/token" -d '{"grant_type":"client_credentials","client_id":"[应用client_id]","client_secret":"[应用] client_secret"}'返回格式{
"access_token":"YWMtWY779DgJEeS2h9OR7fw4QgAAAUmO4Qukwd9cfJSpkWHiOa7MCSk0MrkVIco",
"expires_in":5184000,
"application":"c03b3e30-046a-11e4-8ed1-5701cdaaa0e4"












第二步设置直播流地址curl -X POST -H "Authorization: Bearer [管理员Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms/stream_url -d '{"pc_pull":"[pc拉流地址]","pc_push":"[pc推流地址]","mobile_pull":"[手机拉流地址]","mobile_push":"[手机推流地址]"}'"成功返回格式:{
"action": "post",
"application": "e1a09de0-0e03-11e7-ad8e-a1d913615409",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"pc_pull": true,
"mobile_push": true,
"mobile_pull": true,
"pc_push": true
},
"timestamp": 1494084474885,
"duration": 1,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












2)创建主播
点击IM用户





点击注册IM用户





填写用户信息





创建用户的过程同样也可以通过REST API形式进行curl -X POST -i " https://a1.easemob.com/[应用OrgName]/[应用AppName]/users" -d '{"username":"[用户名]","password":"[密码]"}'
注:应用必须为开放注册





将注册的用户添加为主播curl -X POST -H "Authorization: [管理员Token]" https://a1.easemob.com/[应用OrgName]/[应用AppName]/super_admin -d'{"superadmin":"[IM用户名]"}'返回结果示例:{
"action": "post",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"result": "success"
},
"timestamp": 1496236798886,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












3)创建直播
点击直播





点击新建房间





填写房间信息




创建房间同时也可以使用REST API形式进行详情可以查看http://docs.easemob.com/im/live/server-integration环信官方文档。
4、 小程序demo集成使用
小程序直播购物demo集成官方WebIM SDK详情请查看https://github.com/easemob/webim-weixin-xcx
Demo具体配置如下
打开demo 下sdk配置文件





修改appkey为自己应用的appkey





打开pages/live/index.js修改房间默认拉流地址及直播间房间号





四、 扩展说明
Demo中房间为固定测试房间,实际使用中应获取环信直播的房间信息及房间列表。具体如下:
获取直播间列表:curl -X GET -H "Authorization: Bearer [用户Token]" https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms?ongoing=true&limit=[获取数量]&cursor=[游标地址(不填写为充开始查询)]
响应:{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"params": {
"cursor": [
"ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6MzE"
],
"ongoing": [
"true"
],
"limit": [
"2"
]
},
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": [
{
"id": "1924",
"chatroom_id": "17177265635330",
"title": "具体了",
"desc": "就咯",
"startTime": 1495779917352,
"endTime": 1495779917352,
"anchor": "wuls",
"gift_count": 0,
"praise_count": 0,
"current_user_count": 8,
"max_user_count": 9,
"status": "ongoing",
"cover_picture_url": "",
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1"
},
{
"id": "1922",
"chatroom_id": "17175003856897",
"title": "香山",
"desc": "随便",
"startTime": 1495777760957,
"endTime": 1495777760957,
"anchor": "sx001",
"gift_count": 0,
"praise_count": 8,
"current_user_count": 1,
"max_user_count": 3,
"status": "ongoing",
"cover_picture_url": "http://127.0.0.1:8080/easemob- ... ot%3B,
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1"
}
],
"timestamp": 1496303336669,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"cursor": "ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6NDk",
"count": 2
}












获取直播间详情:curl -X GET -H "Authorization: Bearer [用户Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/[房间id]/status"响应:{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"liveRoomID": "1946",
"status": "ongoing"
},
"timestamp": 1496234759930,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"count": 0
}














 
使用环信直播购物小程序遇到任何问题欢迎跟帖讨论。 查看全部
今天你看直播了吗?
拥有10亿微信生态用户的小程序已经成为了继移动互联后的又一个现象级风口,随着微信小程序对外开放实时音视频录制及播放等更多连接能力,小程序与直播强强联合,在各行各业找到了非常多的玩法,小程序直播相比微信直播和APP直播更加简洁、流畅、低延时、多入口等众多优势迅速向商业直播领域及泛娱乐直播领域蔓延。从小游戏、内容付费、工具、大数据、社交电商创业者到传统品牌商们,都在努力搭上小程序直播这辆快车,以免错过微信生态里新的流量洼地。
 
微信图片_20180725162426.jpg


作为一名环信生态圈资深开发者,本着对技术的热衷,对环信的眷恋和对党的忠诚,基于环信即时通讯云写了“直播购物小程序”,目前项目源码已全部免费开放,希望对有需求的企业和开发者提供一个思路和参考。
直播购物小程序源码github地址:https://github.com/YuTongNetworkTechnology/wechat_live/tree/master 
git打不开可直接点下面链接下载



预览图.jpg

直播购物小程序运行预览图 
 
小程序体验指南(仅需两步):
 
1、下载微信小程序开发工具,下载地址:https://developers.weixin.qq.c ... .html 
 
Catch9A07(07-20-17-38-30).jpg

2、导入源码:将附件的源码解压直接导入 


Catch1C69(07-20-17-38-30).jpg


环信小程序直播技术文档
一、 使用的技术
1、 环信IM直播室。
2、 微信小程序实时音视频播放组件live-player。
3、 推流软件(obs、易推流)等推流。
4、 视频流服务器(UCLOUD、七牛、腾讯)等视频流服务器。
二、 系统使用流程。
1、 视频推流软件将视频流推到流服务器。
2、 打开视频直播demo小程序注册环信账号。
3、 进入软件直播室进行测试。
三、 技术流程及使用的SDk
1、 注册环信账号
打开https://www.easemob.com/ 环信官网,点击右上角注册按钮,选择[注册即时通讯云]
1.png

填写对相关信息进行注册

2.png

注册成功后进行登录
3.png

注:新注册用户需进行账号的认证。
2、 直播应用创建
登录成功点击应用列表选择创建应用
4.png

输入应用名称等信息
 

5.png

创建成功后点击应用进入

6.png

需要注意的是应用的OrgName 和AppName这两个是以后都需要用到的两个参数变量
7.png

3、 直播创建
1)在创建直播之前需要对应用进行设置首先需要设置应用的直播流地址
第一步获取应用管理员的Token
curl -X POST "https://a1.easemob.com/[应用OrgName]/[应用AppName]/token" -d '{"grant_type":"client_credentials","client_id":"[应用client_id]","client_secret":"[应用] client_secret"}'
返回格式
{
"access_token":"YWMtWY779DgJEeS2h9OR7fw4QgAAAUmO4Qukwd9cfJSpkWHiOa7MCSk0MrkVIco",
"expires_in":5184000,
"application":"c03b3e30-046a-11e4-8ed1-5701cdaaa0e4"












第二步设置直播流地址
curl -X POST -H "Authorization: Bearer [管理员Token]"  " https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms/stream_url -d '{"pc_pull":"[pc拉流地址]","pc_push":"[pc推流地址]","mobile_pull":"[手机拉流地址]","mobile_push":"[手机推流地址]"}'"
成功返回格式:
{
"action": "post",
"application": "e1a09de0-0e03-11e7-ad8e-a1d913615409",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"pc_pull": true,
"mobile_push": true,
"mobile_pull": true,
"pc_push": true
},
"timestamp": 1494084474885,
"duration": 1,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












2)创建主播
点击IM用户

8.png

点击注册IM用户

9.png

填写用户信息

10.png

创建用户的过程同样也可以通过REST API形式进行
curl -X POST -i " https://a1.easemob.com/[应用OrgName]/[应用AppName]/users" -d '{"username":"[用户名]","password":"[密码]"}'

注:应用必须为开放注册

11.png

将注册的用户添加为主播
curl -X POST -H "Authorization: [管理员Token]"  https://a1.easemob.com/[应用OrgName]/[应用AppName]/super_admin -d'{"superadmin":"[IM用户名]"}'
返回结果示例:
{
"action": "post",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"result": "success"
},
"timestamp": 1496236798886,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui"
}












3)创建直播
点击直播

12.png

点击新建房间

13.png

填写房间信息
14.png

创建房间同时也可以使用REST API形式进行详情可以查看http://docs.easemob.com/im/live/server-integration环信官方文档。
4、 小程序demo集成使用
小程序直播购物demo集成官方WebIM SDK详情请查看https://github.com/easemob/webim-weixin-xcx
Demo具体配置如下
打开demo 下sdk配置文件

15.png

修改appkey为自己应用的appkey

16.png

打开pages/live/index.js修改房间默认拉流地址及直播间房间号

17.png

四、 扩展说明
Demo中房间为固定测试房间,实际使用中应获取环信直播的房间信息及房间列表。具体如下:
获取直播间列表:
curl -X GET -H "Authorization: Bearer  [用户Token]"  https://a1.easemob.com/[应用OrgName]/[应用AppName]/liverooms?ongoing=true&limit=[获取数量]&cursor=[游标地址(不填写为充开始查询)]

响应:
{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"params": {
"cursor": [
"ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6MzE"
],
"ongoing": [
"true"
],
"limit": [
"2"
]
},
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": [
{
"id": "1924",
"chatroom_id": "17177265635330",
"title": "具体了",
"desc": "就咯",
"startTime": 1495779917352,
"endTime": 1495779917352,
"anchor": "wuls",
"gift_count": 0,
"praise_count": 0,
"current_user_count": 8,
"max_user_count": 9,
"status": "ongoing",
"cover_picture_url": "",
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1924_1"
},
{
"id": "1922",
"chatroom_id": "17175003856897",
"title": "香山",
"desc": "随便",
"startTime": 1495777760957,
"endTime": 1495777760957,
"anchor": "sx001",
"gift_count": 0,
"praise_count": 8,
"current_user_count": 1,
"max_user_count": 3,
"status": "ongoing",
"cover_picture_url": "http://127.0.0.1:8080/easemob- ... ot%3B,
"pc_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"pc_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_pull_url": "rtmp://vlive3.rtmp.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1",
"mobile_push_url": "rtmp://publish3.cdn.ucloud.com.cn/ucloud/easemob-demo_chatdemoui_1922_1"
}
],
"timestamp": 1496303336669,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"cursor": "ZGNiMjRmNGY1YjczYjlhYTNkYjk1MDY2YmEyNzFmODQ6aW06Y2hhdHJvb206ZWFzZW1vYi1kZW1vI2NoYXRkZW1vdWk6NDk",
"count": 2
}












获取直播间详情:
curl -X GET -H "Authorization: Bearer [用户Token]" " https://a1.easemob.com/[应用OrgName]/[应用AppName]/[房间id]/status"
响应:
{
"action": "get",
"application": "4d7e4ba0-dc4a-11e3-90d5-e1ffbaacdaf5",
"uri": "http://127.0.0.1:8080/easemob- ... ot%3B,
"entities": [ ],
"data": {
"liveRoomID": "1946",
"status": "ongoing"
},
"timestamp": 1496234759930,
"duration": 0,
"organization": "easemob-demo",
"applicationName": "chatdemoui",
"count": 0
}














 
使用环信直播购物小程序遇到任何问题欢迎跟帖讨论。
19
评论

【新手快速入门】集成环信常见问题+解决方案汇总

dujiepeng 发表了文章 • 26106 次浏览 • 2017-05-22 15:51 • 来自相关话题

   这里整理了集成环信的常见问题和一些功能的实现思路,希望能帮助到大家。感谢热心的开发者贡献,大家在观看过程中有不明白的地方欢迎直接跟帖咨询。
 
ios篇
APNs证书创建和上传到环信后台头像昵称的简述和处理方案音视频离线推送Demo实现环信服务器聊天记录保存多久?离线收不到好友请求IOS中环信聊天窗口如何实现文件发送和预览的功能ios集成常见问题环信推送的一些常见问题实现名片|红包|话题聊天室等自定义cell
 
Android篇
Android sdk 的两种导入方式环信3.0SDK集成小米推送教程EaseUI库中V4、v7包冲突解决方案Android EaseUI里的百度地图替换为高德地图android扩展消息(名片集成)关于会话列表的置顶聊天java.lang.UnsatisfiedLinkError: 的问题android 端 app 后台被杀死收不到消息的解决方案
昵称头像篇
android中如何显示开发者服务器上的昵称和头像 Android中显示头像(接上一篇文章看)环信(Android)设置头像和昵称的方法(最简单暴力的基于环信demo的集成)IOS中如何显示开发者服务器上的昵称和头像【环信公开课第12期视频回放】-所有关于环信IM昵称头像的问题听这课就够了
 
直播篇
一言不合你就搞个直播APP
 
客服集成
IM-SDK和客服SDK并存开发指南—Android篇IM-SDK和客服SDK并存开发指南—iOS篇
 
开源项目
Android简版demoios简版demo凡信2.0:超仿微信的开源项目 凡信3.0:携直播和红包而来高仿微信:Github 3,515 Star方圆十里:环信编程大赛冠军项目泛聊:定一个小目标写一个QQSlack聊天机器人:一天时间做一个聊天机器人TV视频通话:在电视上视频通话视频通话:Android手机视频通话酷信:ios高仿微信公众号助手:与订阅用户聊天沟通
 
持续更新ing...小伙伴们还有什么想知道欢迎跟帖提出。
  查看全部
   这里整理了集成环信的常见问题和一些功能的实现思路,希望能帮助到大家。感谢热心的开发者贡献,大家在观看过程中有不明白的地方欢迎直接跟帖咨询。
 
ios篇

 
Android篇

昵称头像篇

 
直播篇
  1. 一言不合你就搞个直播APP

 
客服集成
  1. IM-SDK和客服SDK并存开发指南—Android篇
  2. IM-SDK和客服SDK并存开发指南—iOS篇

 
开源项目

 
持续更新ing...小伙伴们还有什么想知道欢迎跟帖提出。
 
1
评论

如何构建分布式SFU/MCU媒体服务器? SFU_MCU

beyond 发表了文章 • 571 次浏览 • 2019-11-26 14:40 • 来自相关话题

本文来自英特尔实时通信解决方案架构师 段先德在LiveVideoStackCon2019上海大会的分享,详细介绍了英特尔在进行分布式SFU/MCU媒体服务器的架构设计中秉持的一些设计原则以及关键问题的解决思路。
大家好,我是来自英特尔上海研发中心的段先德。从2014年开始主要做基于WebRTC的实时通信和统一通信解决方案。对于实时通讯来说WebRTC技术是一个革命性的存在。2014年4月英特尔发布了Intel® Collaboration Suite for WebRTC,这是一款可免费使用的包含服务器侧程序和客户端SDK的完整解决方案。经过多年的迭代更新,当前最新发布的是4.2版本。

1. Requirements and Design Principles

本次分享的内容主要分为三个部分,首先介绍英特尔ICS for WebRTC项目中要解决的问题;其次介绍我们在解决这些问题的时候的指导思想和整体设计原则;最后介绍我们的解决方案目前的状态以及当下和近期要做的一些事情。

1.1 Functional Requirements






我们项目团队最初的出发点是希望能做一套够达到一般功能性要求的基于互联网的视频会议解决方案。譬如可以支持WebRTC和SIP终端,实现接入到同一个会议中。SIP主要针对的是存量设备,重点是对WebRTC终端的支持。WebRTC接入相比于很多以前存量的企业视频会议解决方案有很多的突破,从2011年以后Chrome在端多媒体系统,弱网对抗方面以及音视频处理这方面一直在持续的改进。

英特尔很早就注意到在WebRTC时代,亟需一个统一的终端和服务器侧的解决方案。我们需要把企业内外的一些移动终端、桌面应用、浏览器、传统的SIP终端设备都支持起来,需要支持NAT穿越和屏幕共享,需要支持服务器侧音视频录制,等等。这里面很多功能性需求通过传统SIP的解决方案做起来很不方便或者成本很高,但是在WebRTC时代,在基于互联网应用的技术思路下,可以很便捷、很优雅地解决这些问题,于是我们在2014年做了ICS for WebRTC v1.0。之后在2016年和2017年之间直播类的应用大爆发使得有些客户希望我们的解决方案里面能够支持直播类场景,把实时互动场景下的音视频流通过RTMP/RTSP/HLS/Dash推送到现有的CDN网络里面去。基于这类需求,我们在功能性方面增加了互动Streaming的能力。

2018年到现在,直播的用户体验要求越来越高,客户希望主播和粉丝或者观众之间的互动能够非常平滑的切换,同时端到端的时延也能够做得更好,也就是希望做到保证端到端的实时性的前提下,在单个呼叫里支持海量的用户连接。这就要求服务器侧系统既要有非常大的“扇出”能力,要支持终端连接在“发布者”和“订阅者”之间非常平滑地进行切换。我们目前正在做的就是把目前的解决方案扩展到这种能够支持大规模并发的“实时互动广播”,初步目标是单个呼叫里达到百万以上的并发连接,而且端到端的时延能够全球控制在300毫秒以内。关于端到端时延,我们在国内互联网上做过一些小规模的测试,测试结果的时延是150毫秒以内。我们还希望这个解决方案能够很方便封装成类似于CDN的服务访问接口或者形式,以便集成到客户现有的直播解决方案中去。

我们当前的解决方案已经具备了非常灵活的服务器侧媒体处理,服务器端可以做音视频的混音混流,比如说当前的一个呼叫里面有十几个参与方,有的参与方希望订阅呼叫中其他参与方发布的原始流,有的参与方希望订阅所有或部分参与方的mix流,有的参与方希望订阅符合自己对codec、分辨率、帧率、码率等定制化要求的转发流,我们当前的解决方案已经可以很好地支持这些需求。

1.2 Nonfunctional Requirements






如果仅仅是为了达到前面所讲的各种功能性需求,随便选择一个现有的开源框架去改改,再自己从头写一些功能模块拼凑一下,总可以整出一个PoC的版本或可以初步走向产品的东西。如果是要严肃地做一个打算把它放到生产环境去运营的产品级别的东西,真正考验这个解决方案的生命力的其实是它在非功能性需求方面的取舍和功力。即使是选择现有的开源框架去做产品,这个框架对非功能性方面的考量也是最重要的决定因素。

在非功能性方面主要关注的点有三个方面。

一是系统的可扩展性,它的服务部署规模可大可小,可以小到在一台英特尔®️ 酷睿™️i7的PC上部署使用,大到一个集群几百台甚至上千台机器组成一个大的cluster上部署使用。另外呼叫的参与方式可以是两三个人的讨论会,或者十几个人一般视频会议,又或者是几十人的在线课堂。部署时可以在当前的系统容量不足时在不中断业务的前提下增加或者删减当前部署的规模,达到很灵活的Scale in/Scale out。

二是容错性,容错能力大多描述都比较抽象,但是落实到系统在做设计的时候要考虑的东西就是非常具体的设计决策,在系统设计里面我们会强调甚至固执的坚持每一个部件都可能会出错,运行时都会发生crash,这就需要在流程设计或者一般逻辑里面handle这些问题,在系统发生部分失效的时候,要能够做到自动恢复或服务优雅降级。

三是分布式部署,单台机器上单实例的部署是不可能做容错的,只有分布式的部署才能够做到。我们要求允许把任何部件部署在数据中心的多台机器上面。我们现在进一步的要求是要能够把任何部件部署在多个数据中心,进行跨数据中心的分布式部署。

2.Unified Media Spread Model UMSM)
2.1 Modularization at Runtime






要满足上述的各种功能性和非功能性需求,就需要在概念模型上对系统的各个部件进行足够的抽象,将逻辑上独立的部件封装到运行时独立的模块里面——即模块化。不管是从单一职责的角度来说,还是从系统的可组合性来说,模块化是自始至终不能打破的一个原则,是我们当前系统——也是很多复杂系统进行架构的第一原则。在我们的系统设计中,对于跟客户端交互的部件来说,要把信令和媒体分开。对于媒体部分来说,媒体的接入部分和处理部分一定是分开的,直接和用户打交道的部分和后台内部的一些处理部件,不管是从单一职责角度来讲还是从面向接口的健壮性要求来讲都必须把它们分开。

我们的服务器侧系统在运行时可以分成五大块。

第一块就是跟客户端进行信令交互的部件,即图中的WebRTC Portal和SIP Portal。他们跟WebRTC客户端和SIP终端进行信令交互。值得注意的一点是WebRTC标准对信令交互的格式和通道没有规定,我们采用的是一种承载在socket.io通道中的私有协议。

第二块是跟客户端进行音视频媒体交互的部件,即图中的WebRTC Agent、Streaming Agent、SIP Agent和Recording Agent。其中WebRTC Agent负责跟客户端之间建立PeerConnection连接,SIP Agent跟SIP终端RTP流进行传输,Streaming Agent是针对RTSP/RTMP/HLS/Dash流,我们可以把IPCamera的RTSP流作为输入直接拉到系统里面来,也可以把系统里面任何一个输入流/合成流/转码后的流作为输出推送到RTMP Server上去,Recording虽然是完全发生在服务器侧的行为,但实际上在概念层次上面是更接近于流的输出。所以在概念模型里我们也把Recording Agent当做媒体接出部件,以达到概念模型的一致性。

第三块是媒体处理的部件,即图中的Audio Agent和Video Agent。Audio Agent是进行音频混音转码工作的部件,Video Agent是视频的合屏和转码的部件,这些所有的部件都是单独部署独立进程在运行。

第四块是呼叫控制的部件,即图中的Conference Agent。我们的系统还是将多方实时音视频通信作为场景基础,Conference Agent就是一通呼叫的总控制部件,它负责room中的参与者、流、订阅关系的控制和管理。对于像远程教育、远程医疗、远程协助之类的其他场景,我们主要是通过对Conference Agent来进行拓展和增强去支持。

第五块就是一些支持部件。整个服务器系统在运行和单机运行时都是cluster形式,Cluster Manager就是一个简单的cluster管理器。视频会议场景中会有一些room的预配置和管理,room的配置数据存放在MongoDB中,管理员都是通过OAM UI通过RESTful API访问Management API部件实现数据访问并受理REST请求。另外各个部件之间的rpc是架设在RabbitMQ消息队列上的。

2.2 Strong Isolation






第二个原则就是要做强隔离。在系统里面坚持执行的原则就是要做强隔离,运行时一定是把看到的逻辑上面独立部件,把它在物理上也做成完全独立的运行时进程。比如像信令受理部件和信令执行部件就是分别独立的进程。这样做使得信令受理部件可以独立于呼叫控制里面的业务逻辑而存在。同理媒体接入部件和媒体处理部件也是分别独立进程。这里的进程就是OS语义上面进程,是我们服务器侧系统构建的基本元素,是生命体的细胞,不同的部件之间进行通讯唯一的方式就是message passing(消息传递)。在概念模型里面看的得到部件都是用单独的Worker进程来处理一个独立的Job。比方说一个Video Agent生成出来的Video Node,它的职责要么是做一个视频混流器,要么是做一个视频转码器,单独运行,独立工作。这样做一方面是进行错误隔离一个部件中产生的异常不会传染影响其他部件,一方面是各个运行时部件可以进行运行时单独进行升级替换。

2.3 Hierarchy in Media Accessing/Processing






第三个原则就是层次化。具体体现在在媒体接入和媒体处理的一些部件的设计和实现上,这些部件在南北(纵)向上面有明确的层次划分,自下而上分为包交互层、帧交互层和内容操作层。以媒体接入部件为例,我们服务器侧系统需要跟各种外围系统和终端进行媒体交互,有的媒体是通过RTP/SRTP包的形式输入、输出,有的媒体是直接以AVStream的行书输出、输出。当媒体进入到我们服务器侧系统内部以后,我们希望有一个统一的格式让它在所有的媒体相关部件之间自由流转,所以我们就定义了统一的MediaFrame格式,所有输入的媒体在媒体接入部件上被组装成MediaFrame。处理MediaFrame的逻辑我们把它放在帧交互层,与客户端进行RTP/SRTP交互的逻辑我们放在包交互层。另外,MediaFrame进入媒体处理部件后,如果涉及到raw格式的操作——譬如合屏、色彩调整、添加水印、替换背景等——我们就把相关逻辑放在内容操作层。

2.4 Media Pipeline in WebRTC Node






设计原则讲起来太枯燥,举两个例子。

第一个是WebRTC Node中的Pipeline结构。在WebRTCNode上面有一个明确的一个界限,广为人知的一些开源的框架里面有一些SFU框架是直接做RTP包的高级转发,而在我们的解决方案里于所有的外部媒体进入到系统里面会先将它们整理成统一的媒体(帧集的封装)之后在各个结点之间进行传输。除了使得层次分明便于系统横向扩展以外,另外一大好处就是把RTP传输相关的事务都终结在媒体接入部件(节点)上,RTP传输中的丢包、乱序等问题的处理不会扩散到系统其它部件。

2.5 Media Pipeline in Video Node (Video Mixer)






第二个例子是视频混流器内部的Pipeline结构。视频混流的部件在Pipeline上面进出都是视频帧,图上紫颜色的模块进出的都是视频已编码的帧,在视频处理部件的内部可以是一些已编码的帧,也可以是一些Scaler和Convertor。使得各个层次的处理器接口非常清楚,便于做成plugable。

2.6 Unified Media Spread Model (UMSM)






前面我们根据系统的功能性和非功能性需求,把系统拆成了一个个松散的部件。那么,怎么把这些部件捏合到一起成为一个有机的系统呢?特别是针对各个媒体接入部件和媒体处理部件之间的媒体交互,我们需要定义一个统一的内部媒体交互模型——我们称之为UMSM。

音视频媒体在系统内部流动,我们采用的是一个“发布-订阅”结构的流基本拓扑。如图所示,系统有一个发布者发布一个流进入到系统里,此时有两个订阅者,其中一个订阅者希望订阅发布的原始流的直接转发流,另外一个订阅者希望订阅房间里面所有的原始流合成流合屏以后的mix流,流的发布者和订阅者的PeerConnection连接建立在不同的WebRTC Node上面,通过PeerConnection进入WebRTC Node的SRTP包流,经过解密,被整理封装成MediaFrame(Audioframe/Videoframe),之后再在不同的部件之间进行传递,如果有订阅者需要的是直接转发流,就把它封装好的音频和视频的帧直接扩散到订阅者所连接的WebRTC Node上面来,如果有订阅者需要合成的流(合屏和混音的流),那么就把混流和混音以后的MediaFrame从AudioNode(Audio Mixer)和VideoNode(Video Mixer)扩散到订阅者所连接的WebRTC Node上。

有了这样一个足够松散的系统内部流扩散结构,无论这些媒体接入部件和媒体处理部件是运行在同一台机器上还是运行在一个数据中心内的不同机器上——甚至运行在位于不同数据中心的不同机器上,都有统一的、一致的流拓扑结构。

2.7 Media Spread Protocol






要实现这样一个流扩散模型,重点要解决两个方面的问题,一个是媒体节点间的传输,另一个是媒体节点的控制。

媒体节点间的传输是面向连接的,因为扩散链路都可能持续比较长的时间,且一般服务器侧部件的部署环境的网络条件是可控的,有利于保障传输质量。另外每一个连接结点间的扩散链路的连接是双向的,因为有可能两个媒体流的接入结点之间存在双向的扩散,以及与媒体流相关的一些feedback信息需要被反向传递,我们希望它能够复用在同一个扩散链路上面。另外我们需要它是可靠的,在以前跟合作伙伴做技术交流的时候他们对于要求流扩散链路必须是可靠的这一点有疑惑。实际上这是一个实时性和可靠性的取舍问题,我们选择在这个环节保证可靠性,而把实时性推给底层去解决,因为如果要在流扩散链路的所有环节处理信号损失,将给上层逻辑带来巨大的复杂性。

2.8 MSP - Transport Control Primitives(WIP)

传输控制就是对于节点间扩散传输链路的控制,目前为了方便在采用的是TCP,在同一数据中心内进行流扩散问题不大,在应用到跨数据中心的部署场景中时,特别是tts和delay比较大的情况下,实际可用的throughput会受比较大的影响,目前仍有一些改进的工作还在进行当中,我们也在调研SCTP和QUIC。

2.9 MSP - Underlying Transport Protocols(TCP vs.QUIC under weak network)






我们在节点间扩散时加一些网损的情况下用TCP和QUIC有做过一些对比测试。QUIC和TCP都是可靠传输,在有网损的时候都会产生一些重传或者是冗余,但是他们不同的拥塞控制策略会对端到端的媒体传递的质量产生不同的影响。我们的对比测试中,发送端是以恒定的码率和帧率(24fps)向服务器侧发送视频流,服务器侧在节点间分别采用TCP和QUIC进行节点间媒体流扩散,图中截取的是相同的网损条件下接收端收到的实际帧率,在5%的丢包和30ms delay时, TCP的帧率就会抖动的非常厉害,在接收端体验就会看到点不流畅,能明显地看到它的卡顿。当加上10%的丢包时波动就跟家剧烈,有时甚至降低到0fps,接收端的用户体验就是非常明的卡顿。相比而言,在QUIC上面还能够看到,接收端的帧率能够更好地坚持在24fps上下,接收端的流畅度更好。总体来看,QUIC是在弱网环境下进行节点间流扩散的一个不错的备选传输。

2.10 MSP - Media Control Primitives






媒体控制的操作对于媒体节点来说,一个publish就是往媒体结点上面发布一路流,给它增加一个input,一个subscribe就是在它上面去增添一个output,linkup就是把一个input和output接续起来,cutoff就把一个input和一个output拆开。对于媒体处理的结点有一些内生的流,generate就是让它产生一路流指定规格(codec、分辨率、帧率、码率、关键帧间隔等),degenerate就是让它取消正在生成中的一个流。

3.Cross DC Media Spread
3.1 Cross DC Media Spread:Relay Node (WIP)






做TCP和QUIC的对比调研目的就是解决跨数据中心通过Internet进行节点间媒体流扩散的实时性(本质是throughput)问题。由于在跨数据中心媒体扩散的时候需要在Internet上面做流扩散,Internet在传输质量上讲没有在数据中心里的效果那么满意,需要找一些基于UDP改进的可靠传输协议去尝试,我们调研过SCTP和QUIC,总体来看QUIC的表现是相当不错的。

同时为了减少同一条流在两个数据中心的多个节点间传输,我们增加了一个Relay Agent(Node)的部件,使得同一条流在两个数据中心之间只需要扩散一次。Relay Agent的另一个作用是进行流扩散的时候的路由控制,譬如一个集团公司的很多分支机房并不是BGP的,需要将流汇聚到指定的BGP机房才能更好地向其他地区数据中心扩散。

3.2 Access Node(Agent) Scheduling






在部署了多个接入节点以后,除了通过增加接入节点来扩充系统的scalability,我们还希望能够利用接入节点的不同地理位置给靠近它的终端用户做就近接入。以WebRTC Agent为例,在部署WebRTC Agent的时候可以指定它的capacity(能力),capacity上面有两个标签,一个是isp,一个是region。用户在进行通信连接请求的时候,它带上isp和region的preference(喜好),系统在进行WebRTC Agent调度的时候会对所有可用的WebRTC Agent的capacity与用户指定的preference进行匹配,找到最满意的接入结点,最后达到就近接入的目的。

在符合preference的候选不止一个时,系统还提供基于work load和历史使用记录进行last-used、least-used、round-robin、random等调度策略,选取符合指定策略的接入节点。

3.3 CDN alike Service






解决了跨数据中心部署的媒体流扩散和调度问题后,我们的解决方案就可以提供更广阔的实时多方音视频通信服务。特别是有了Relay Agent的级联能力后,我们服务器侧系统就可以得到极大的提升,譬如假设单个媒体接入节点的扇出能力是1:1000的话,经过一级级联后就能达到1:100万,经过两级级联后就能达到1:10亿,已经堪比一般CDN的扇出能力了。而CDN的就是本质是一个分布式的cache系统,cache是实时应用的天敌。许多既要求海量扇出比,又要求实时性,并且要随时平滑进行流拓扑切换的场景下,CDN就显得无能为力了,而我们的解决方案将覆盖这些场景,特别是在5G和IoT的时代。

原文发布于微信公众号 - LiveVideoStack(livevideostack) 查看全部
本文来自英特尔实时通信解决方案架构师 段先德在LiveVideoStackCon2019上海大会的分享,详细介绍了英特尔在进行分布式SFU/MCU媒体服务器的架构设计中秉持的一些设计原则以及关键问题的解决思路。
大家好,我是来自英特尔上海研发中心的段先德。从2014年开始主要做基于WebRTC的实时通信和统一通信解决方案。对于实时通讯来说WebRTC技术是一个革命性的存在。2014年4月英特尔发布了Intel® Collaboration Suite for WebRTC,这是一款可免费使用的包含服务器侧程序和客户端SDK的完整解决方案。经过多年的迭代更新,当前最新发布的是4.2版本。

1. Requirements and Design Principles

本次分享的内容主要分为三个部分,首先介绍英特尔ICS for WebRTC项目中要解决的问题;其次介绍我们在解决这些问题的时候的指导思想和整体设计原则;最后介绍我们的解决方案目前的状态以及当下和近期要做的一些事情。

1.1 Functional Requirements

1.jpg


我们项目团队最初的出发点是希望能做一套够达到一般功能性要求的基于互联网的视频会议解决方案。譬如可以支持WebRTC和SIP终端,实现接入到同一个会议中。SIP主要针对的是存量设备,重点是对WebRTC终端的支持。WebRTC接入相比于很多以前存量的企业视频会议解决方案有很多的突破,从2011年以后Chrome在端多媒体系统,弱网对抗方面以及音视频处理这方面一直在持续的改进。

英特尔很早就注意到在WebRTC时代,亟需一个统一的终端和服务器侧的解决方案。我们需要把企业内外的一些移动终端、桌面应用、浏览器、传统的SIP终端设备都支持起来,需要支持NAT穿越和屏幕共享,需要支持服务器侧音视频录制,等等。这里面很多功能性需求通过传统SIP的解决方案做起来很不方便或者成本很高,但是在WebRTC时代,在基于互联网应用的技术思路下,可以很便捷、很优雅地解决这些问题,于是我们在2014年做了ICS for WebRTC v1.0。之后在2016年和2017年之间直播类的应用大爆发使得有些客户希望我们的解决方案里面能够支持直播类场景,把实时互动场景下的音视频流通过RTMP/RTSP/HLS/Dash推送到现有的CDN网络里面去。基于这类需求,我们在功能性方面增加了互动Streaming的能力。

2018年到现在,直播的用户体验要求越来越高,客户希望主播和粉丝或者观众之间的互动能够非常平滑的切换,同时端到端的时延也能够做得更好,也就是希望做到保证端到端的实时性的前提下,在单个呼叫里支持海量的用户连接。这就要求服务器侧系统既要有非常大的“扇出”能力,要支持终端连接在“发布者”和“订阅者”之间非常平滑地进行切换。我们目前正在做的就是把目前的解决方案扩展到这种能够支持大规模并发的“实时互动广播”,初步目标是单个呼叫里达到百万以上的并发连接,而且端到端的时延能够全球控制在300毫秒以内。关于端到端时延,我们在国内互联网上做过一些小规模的测试,测试结果的时延是150毫秒以内。我们还希望这个解决方案能够很方便封装成类似于CDN的服务访问接口或者形式,以便集成到客户现有的直播解决方案中去。

我们当前的解决方案已经具备了非常灵活的服务器侧媒体处理,服务器端可以做音视频的混音混流,比如说当前的一个呼叫里面有十几个参与方,有的参与方希望订阅呼叫中其他参与方发布的原始流,有的参与方希望订阅所有或部分参与方的mix流,有的参与方希望订阅符合自己对codec、分辨率、帧率、码率等定制化要求的转发流,我们当前的解决方案已经可以很好地支持这些需求。

1.2 Nonfunctional Requirements

2.jpg


如果仅仅是为了达到前面所讲的各种功能性需求,随便选择一个现有的开源框架去改改,再自己从头写一些功能模块拼凑一下,总可以整出一个PoC的版本或可以初步走向产品的东西。如果是要严肃地做一个打算把它放到生产环境去运营的产品级别的东西,真正考验这个解决方案的生命力的其实是它在非功能性需求方面的取舍和功力。即使是选择现有的开源框架去做产品,这个框架对非功能性方面的考量也是最重要的决定因素。

在非功能性方面主要关注的点有三个方面。

一是系统的可扩展性,它的服务部署规模可大可小,可以小到在一台英特尔®️ 酷睿™️i7的PC上部署使用,大到一个集群几百台甚至上千台机器组成一个大的cluster上部署使用。另外呼叫的参与方式可以是两三个人的讨论会,或者十几个人一般视频会议,又或者是几十人的在线课堂。部署时可以在当前的系统容量不足时在不中断业务的前提下增加或者删减当前部署的规模,达到很灵活的Scale in/Scale out。

二是容错性,容错能力大多描述都比较抽象,但是落实到系统在做设计的时候要考虑的东西就是非常具体的设计决策,在系统设计里面我们会强调甚至固执的坚持每一个部件都可能会出错,运行时都会发生crash,这就需要在流程设计或者一般逻辑里面handle这些问题,在系统发生部分失效的时候,要能够做到自动恢复或服务优雅降级。

三是分布式部署,单台机器上单实例的部署是不可能做容错的,只有分布式的部署才能够做到。我们要求允许把任何部件部署在数据中心的多台机器上面。我们现在进一步的要求是要能够把任何部件部署在多个数据中心,进行跨数据中心的分布式部署。

2.Unified Media Spread Model UMSM)
2.1 Modularization at Runtime

3.jpg


要满足上述的各种功能性和非功能性需求,就需要在概念模型上对系统的各个部件进行足够的抽象,将逻辑上独立的部件封装到运行时独立的模块里面——即模块化。不管是从单一职责的角度来说,还是从系统的可组合性来说,模块化是自始至终不能打破的一个原则,是我们当前系统——也是很多复杂系统进行架构的第一原则。在我们的系统设计中,对于跟客户端交互的部件来说,要把信令和媒体分开。对于媒体部分来说,媒体的接入部分和处理部分一定是分开的,直接和用户打交道的部分和后台内部的一些处理部件,不管是从单一职责角度来讲还是从面向接口的健壮性要求来讲都必须把它们分开。

我们的服务器侧系统在运行时可以分成五大块。

第一块就是跟客户端进行信令交互的部件,即图中的WebRTC Portal和SIP Portal。他们跟WebRTC客户端和SIP终端进行信令交互。值得注意的一点是WebRTC标准对信令交互的格式和通道没有规定,我们采用的是一种承载在socket.io通道中的私有协议。

第二块是跟客户端进行音视频媒体交互的部件,即图中的WebRTC Agent、Streaming Agent、SIP Agent和Recording Agent。其中WebRTC Agent负责跟客户端之间建立PeerConnection连接,SIP Agent跟SIP终端RTP流进行传输,Streaming Agent是针对RTSP/RTMP/HLS/Dash流,我们可以把IPCamera的RTSP流作为输入直接拉到系统里面来,也可以把系统里面任何一个输入流/合成流/转码后的流作为输出推送到RTMP Server上去,Recording虽然是完全发生在服务器侧的行为,但实际上在概念层次上面是更接近于流的输出。所以在概念模型里我们也把Recording Agent当做媒体接出部件,以达到概念模型的一致性。

第三块是媒体处理的部件,即图中的Audio Agent和Video Agent。Audio Agent是进行音频混音转码工作的部件,Video Agent是视频的合屏和转码的部件,这些所有的部件都是单独部署独立进程在运行。

第四块是呼叫控制的部件,即图中的Conference Agent。我们的系统还是将多方实时音视频通信作为场景基础,Conference Agent就是一通呼叫的总控制部件,它负责room中的参与者、流、订阅关系的控制和管理。对于像远程教育、远程医疗、远程协助之类的其他场景,我们主要是通过对Conference Agent来进行拓展和增强去支持。

第五块就是一些支持部件。整个服务器系统在运行和单机运行时都是cluster形式,Cluster Manager就是一个简单的cluster管理器。视频会议场景中会有一些room的预配置和管理,room的配置数据存放在MongoDB中,管理员都是通过OAM UI通过RESTful API访问Management API部件实现数据访问并受理REST请求。另外各个部件之间的rpc是架设在RabbitMQ消息队列上的。

2.2 Strong Isolation

4.jpg


第二个原则就是要做强隔离。在系统里面坚持执行的原则就是要做强隔离,运行时一定是把看到的逻辑上面独立部件,把它在物理上也做成完全独立的运行时进程。比如像信令受理部件和信令执行部件就是分别独立的进程。这样做使得信令受理部件可以独立于呼叫控制里面的业务逻辑而存在。同理媒体接入部件和媒体处理部件也是分别独立进程。这里的进程就是OS语义上面进程,是我们服务器侧系统构建的基本元素,是生命体的细胞,不同的部件之间进行通讯唯一的方式就是message passing(消息传递)。在概念模型里面看的得到部件都是用单独的Worker进程来处理一个独立的Job。比方说一个Video Agent生成出来的Video Node,它的职责要么是做一个视频混流器,要么是做一个视频转码器,单独运行,独立工作。这样做一方面是进行错误隔离一个部件中产生的异常不会传染影响其他部件,一方面是各个运行时部件可以进行运行时单独进行升级替换。

2.3 Hierarchy in Media Accessing/Processing

5.jpg


第三个原则就是层次化。具体体现在在媒体接入和媒体处理的一些部件的设计和实现上,这些部件在南北(纵)向上面有明确的层次划分,自下而上分为包交互层、帧交互层和内容操作层。以媒体接入部件为例,我们服务器侧系统需要跟各种外围系统和终端进行媒体交互,有的媒体是通过RTP/SRTP包的形式输入、输出,有的媒体是直接以AVStream的行书输出、输出。当媒体进入到我们服务器侧系统内部以后,我们希望有一个统一的格式让它在所有的媒体相关部件之间自由流转,所以我们就定义了统一的MediaFrame格式,所有输入的媒体在媒体接入部件上被组装成MediaFrame。处理MediaFrame的逻辑我们把它放在帧交互层,与客户端进行RTP/SRTP交互的逻辑我们放在包交互层。另外,MediaFrame进入媒体处理部件后,如果涉及到raw格式的操作——譬如合屏、色彩调整、添加水印、替换背景等——我们就把相关逻辑放在内容操作层。

2.4 Media Pipeline in WebRTC Node

6.jpg


设计原则讲起来太枯燥,举两个例子。

第一个是WebRTC Node中的Pipeline结构。在WebRTCNode上面有一个明确的一个界限,广为人知的一些开源的框架里面有一些SFU框架是直接做RTP包的高级转发,而在我们的解决方案里于所有的外部媒体进入到系统里面会先将它们整理成统一的媒体(帧集的封装)之后在各个结点之间进行传输。除了使得层次分明便于系统横向扩展以外,另外一大好处就是把RTP传输相关的事务都终结在媒体接入部件(节点)上,RTP传输中的丢包、乱序等问题的处理不会扩散到系统其它部件。

2.5 Media Pipeline in Video Node (Video Mixer)

7.jpg


第二个例子是视频混流器内部的Pipeline结构。视频混流的部件在Pipeline上面进出都是视频帧,图上紫颜色的模块进出的都是视频已编码的帧,在视频处理部件的内部可以是一些已编码的帧,也可以是一些Scaler和Convertor。使得各个层次的处理器接口非常清楚,便于做成plugable。

2.6 Unified Media Spread Model (UMSM)

8.jpg


前面我们根据系统的功能性和非功能性需求,把系统拆成了一个个松散的部件。那么,怎么把这些部件捏合到一起成为一个有机的系统呢?特别是针对各个媒体接入部件和媒体处理部件之间的媒体交互,我们需要定义一个统一的内部媒体交互模型——我们称之为UMSM。

音视频媒体在系统内部流动,我们采用的是一个“发布-订阅”结构的流基本拓扑。如图所示,系统有一个发布者发布一个流进入到系统里,此时有两个订阅者,其中一个订阅者希望订阅发布的原始流的直接转发流,另外一个订阅者希望订阅房间里面所有的原始流合成流合屏以后的mix流,流的发布者和订阅者的PeerConnection连接建立在不同的WebRTC Node上面,通过PeerConnection进入WebRTC Node的SRTP包流,经过解密,被整理封装成MediaFrame(Audioframe/Videoframe),之后再在不同的部件之间进行传递,如果有订阅者需要的是直接转发流,就把它封装好的音频和视频的帧直接扩散到订阅者所连接的WebRTC Node上面来,如果有订阅者需要合成的流(合屏和混音的流),那么就把混流和混音以后的MediaFrame从AudioNode(Audio Mixer)和VideoNode(Video Mixer)扩散到订阅者所连接的WebRTC Node上。

有了这样一个足够松散的系统内部流扩散结构,无论这些媒体接入部件和媒体处理部件是运行在同一台机器上还是运行在一个数据中心内的不同机器上——甚至运行在位于不同数据中心的不同机器上,都有统一的、一致的流拓扑结构。

2.7 Media Spread Protocol

9.jpg


要实现这样一个流扩散模型,重点要解决两个方面的问题,一个是媒体节点间的传输,另一个是媒体节点的控制。

媒体节点间的传输是面向连接的,因为扩散链路都可能持续比较长的时间,且一般服务器侧部件的部署环境的网络条件是可控的,有利于保障传输质量。另外每一个连接结点间的扩散链路的连接是双向的,因为有可能两个媒体流的接入结点之间存在双向的扩散,以及与媒体流相关的一些feedback信息需要被反向传递,我们希望它能够复用在同一个扩散链路上面。另外我们需要它是可靠的,在以前跟合作伙伴做技术交流的时候他们对于要求流扩散链路必须是可靠的这一点有疑惑。实际上这是一个实时性和可靠性的取舍问题,我们选择在这个环节保证可靠性,而把实时性推给底层去解决,因为如果要在流扩散链路的所有环节处理信号损失,将给上层逻辑带来巨大的复杂性。

2.8 MSP - Transport Control Primitives(WIP)

传输控制就是对于节点间扩散传输链路的控制,目前为了方便在采用的是TCP,在同一数据中心内进行流扩散问题不大,在应用到跨数据中心的部署场景中时,特别是tts和delay比较大的情况下,实际可用的throughput会受比较大的影响,目前仍有一些改进的工作还在进行当中,我们也在调研SCTP和QUIC。

2.9 MSP - Underlying Transport Protocols(TCP vs.QUIC under weak network)

11.jpg


我们在节点间扩散时加一些网损的情况下用TCP和QUIC有做过一些对比测试。QUIC和TCP都是可靠传输,在有网损的时候都会产生一些重传或者是冗余,但是他们不同的拥塞控制策略会对端到端的媒体传递的质量产生不同的影响。我们的对比测试中,发送端是以恒定的码率和帧率(24fps)向服务器侧发送视频流,服务器侧在节点间分别采用TCP和QUIC进行节点间媒体流扩散,图中截取的是相同的网损条件下接收端收到的实际帧率,在5%的丢包和30ms delay时, TCP的帧率就会抖动的非常厉害,在接收端体验就会看到点不流畅,能明显地看到它的卡顿。当加上10%的丢包时波动就跟家剧烈,有时甚至降低到0fps,接收端的用户体验就是非常明的卡顿。相比而言,在QUIC上面还能够看到,接收端的帧率能够更好地坚持在24fps上下,接收端的流畅度更好。总体来看,QUIC是在弱网环境下进行节点间流扩散的一个不错的备选传输。

2.10 MSP - Media Control Primitives

12.jpg


媒体控制的操作对于媒体节点来说,一个publish就是往媒体结点上面发布一路流,给它增加一个input,一个subscribe就是在它上面去增添一个output,linkup就是把一个input和output接续起来,cutoff就把一个input和一个output拆开。对于媒体处理的结点有一些内生的流,generate就是让它产生一路流指定规格(codec、分辨率、帧率、码率、关键帧间隔等),degenerate就是让它取消正在生成中的一个流。

3.Cross DC Media Spread
3.1 Cross DC Media Spread:Relay Node (WIP)

13.jpg


做TCP和QUIC的对比调研目的就是解决跨数据中心通过Internet进行节点间媒体流扩散的实时性(本质是throughput)问题。由于在跨数据中心媒体扩散的时候需要在Internet上面做流扩散,Internet在传输质量上讲没有在数据中心里的效果那么满意,需要找一些基于UDP改进的可靠传输协议去尝试,我们调研过SCTP和QUIC,总体来看QUIC的表现是相当不错的。

同时为了减少同一条流在两个数据中心的多个节点间传输,我们增加了一个Relay Agent(Node)的部件,使得同一条流在两个数据中心之间只需要扩散一次。Relay Agent的另一个作用是进行流扩散的时候的路由控制,譬如一个集团公司的很多分支机房并不是BGP的,需要将流汇聚到指定的BGP机房才能更好地向其他地区数据中心扩散。

3.2 Access Node(Agent) Scheduling

14.jpg


在部署了多个接入节点以后,除了通过增加接入节点来扩充系统的scalability,我们还希望能够利用接入节点的不同地理位置给靠近它的终端用户做就近接入。以WebRTC Agent为例,在部署WebRTC Agent的时候可以指定它的capacity(能力),capacity上面有两个标签,一个是isp,一个是region。用户在进行通信连接请求的时候,它带上isp和region的preference(喜好),系统在进行WebRTC Agent调度的时候会对所有可用的WebRTC Agent的capacity与用户指定的preference进行匹配,找到最满意的接入结点,最后达到就近接入的目的。

在符合preference的候选不止一个时,系统还提供基于work load和历史使用记录进行last-used、least-used、round-robin、random等调度策略,选取符合指定策略的接入节点。

3.3 CDN alike Service

15.jpg


解决了跨数据中心部署的媒体流扩散和调度问题后,我们的解决方案就可以提供更广阔的实时多方音视频通信服务。特别是有了Relay Agent的级联能力后,我们服务器侧系统就可以得到极大的提升,譬如假设单个媒体接入节点的扇出能力是1:1000的话,经过一级级联后就能达到1:100万,经过两级级联后就能达到1:10亿,已经堪比一般CDN的扇出能力了。而CDN的就是本质是一个分布式的cache系统,cache是实时应用的天敌。许多既要求海量扇出比,又要求实时性,并且要随时平滑进行流拓扑切换的场景下,CDN就显得无能为力了,而我们的解决方案将覆盖这些场景,特别是在5G和IoT的时代。

原文发布于微信公众号 - LiveVideoStack(livevideostack)