您当前的位置是:  首页 > 技术 > 企业通信 > 技术 > 视频通讯 > 解决方案 >
技术 - 企业通信 - 视频通讯技术频道
  首页 > 技术 > 企业通信 > 技术 > 视频通讯 > 解决方案 > XSWITCH大规模视频会议解决方案

XSWITCH大规模视频会议解决方案

2019-11-05 14:43:50   作者:   来源:   评论:0  点击:


  我们在开发FreeSWITCH视频会议系统的过程中,经常遇到智慧党建相关的视频会议需求。考虑到会议规模比较大,FreeSWITCH的转码性能又不好,就一直没敢接。后来有老朋友找到我们,不好拒绝,就做了一套解决方案,两年多过去了,运行良好,也走了一些弯路,在此跟大家分享一下。
  会议的使用场景大致是从上到下开大会,区县级组织部为主会场,开到乡镇及行政村。主会场的视频发送到下级,同时主会场可以随时查看各分会场视频,了解大家参会及学习情况。除了集体讲课外,还有互动讨论等,可以选择不同的会场发言。
  我们全部使用SIP解决方案。在硬件选择上,主会场我们使用了GrandStream GXV3202设备,支持SIP视频会议及双流。村镇级会场酌情使用GXV3202或质优价廉的机顶盒。
  我们使用FreeSWITCH做为视频会议的平台。但是,FreeSWITCH单机无法支撑大规模的转码会议,项目又比较紧急。所以,我们最初采用了最简单的视频会议方式,即不转码,不融屏,仅做视频转发的方式。这种方式有很多限制,比如所有参会方只能看到相同的内容,我们也没法打字幕。我们实现了一个Web界面,可以自动轮循切换所有会场,算是在一定程度上解决了第一个问题,字幕的解决方案就是在会场现场后面挂横幅或者放桌牌。
  毕竟是能开会了,我们也在单机上做到了大约400路并发的规模,开了三次会,都比较成功。
  在开会的过程中,我们抓紧开发能转码融屏的会议。首先要解决的问题就是多机会议串联。我们采用了一主多从的结构。即主会场全部拨入主服务器,而下级分会场拨入从服务器。主服务器和从服务器的会议室串联。为了避免出现「看对眼」(即一路视频信号上行又下行看到的画面会无限循环)的情况,也是为了解决不同会场看不同画面,我们采用两个画布实现——上行视频永远在画布2上,下行视频永远在画布1上。
  实验成功,最后我们用了5台服务器搭建了一个集群,可以转码融屏,也可以打字幕了。但,这只是我们恶梦的开始。
  首先我们发现机顶盒顶不住了,经常会出现花屏、卡顿,甚至死机。机顶盒版本比较老,上面有一个SIP终端软件,是第三方开发的,对于我们来讲就相当于一个黑盒子,除了不断地测试修改各种视频参数,我们确实也没有更好的办法进行调试。不过,在经过无数次的实验后,我们还是找到了一些可行的参数,做到了720p高清视频,质量不是最优,但是也算是足够好了。
  主会场实拍

多画面
  大规模系统的另一个难点就是测试,虽然我们也部署了自动化的测试,但测起来跟真实的场景数据有诸多出入,后来还是部署了人肉方式,放了一大批机顶盒实际入会测试。
  机顶盒测试
  项目是跟山东有线合作的,他们有很好的网络基础设施,人员配合也很到位。但无论如何并发就是上不去。又经过无数有猜测与调试,请教了业界高人的情况下把问题基本定位到Linux内核的瓶颈。这……好像有点超纲了。一次偶然的机会换了台机器测试,发现网络瓶颈竟然不存在了,原因只是那台机器的网卡不一样。后来,我们把所有服务器都换成了那个型号的网卡。
  在实现过程中,我们也给FreeSWITCH打了一些补丁,主要是完成级联的控制,以及修复一些Bug,做了一些优化。比如与会者比较多,在大部分会场不上镜(没有人看该会场的画面)的情况下,我们就停止对该会场的视频进行解码,以节省CPU。
  当然,在打补丁的过程中我们也成功地植入了自己的Bug。在第一次上线的时候,测试了一整天,到了晚上临近开会的时候,发现内存在默默地增长,如此下去,根本撑不过晚上的会议,一身汗。好在我们提前部署了sofia recover,直接强制所有FreeSWITCH崩溃,重启后仅有少数会场掉线,避免了最大的灾难,顺利撑过了两个多小时的会议。
  会后我们连夜把内存泄漏给修复了,至此,视频会议系统算是可以交差了。又经过几轮优化,现在,我们的平台已经有了正式的名称,叫XSWITCH。
  后来我们也实现了很多热修复的手段,比如将所有在线的用户都转到echo Application,修复后reload mod_conference,再转回来。因为毕竟协调几百个机顶盒重新爱博体育赞助巴塞一遍也是很难的。
  下图是多级级连示意图。主会场采集的视频图像放到主服务器的画布1上,下发到从服务器进而下发到终端。各终端图像首先汇聚到从服务器画布2上,上行到主服务器画布2,主会场随时可以选择观看画布1或画布2。
  多级级连示意图
  使用这种方案,在终端数量增多时我们可以线性横向扩展。
  会议系统运行以来,状态良好。最近,我们完成了为期三天的视频会议保障,涉及到600多个终端(乡镇及行政村),万名党员,顺便采集到一些技术数据。
  下图是某服务器200多个终端的带宽情况。
  某服务器200+终端
  下图是综合视图。
  会控界面显示该会议中共有434个终端入会。
  会控界面
  会控界面显示各服务器的统计情况。显示该会议中共有504个终端入会。
  CPU内存的监控情况。
  以上只是部分统计数据。当时服务器上还有其它并行的会议在开。总得来看,由于我们做了转码优化,CPU反而没有什么瓶颈了,而瓶颈在于网卡。我们暂时使用上行2M下行1M的码率,理论上千兆的网卡可以支撑500路,或打8折400路的并发。我们暂时最大只跑了200多路,潜力有待进一步验证。
  下一步的优化方案也很清晰:
  增加一块网卡可以提高一倍并发
  使用动态码率控制,在参会方不上镜的时候降低码率或停发视频,但需要客户端配合
  感谢各位领导的信任与支持,也感谢所有党员同志们的大力支持。我们一定不会放过持续优化的机会,争取发挥出硬件最大的性能,这是我们程序员的追求,也是我们的责任。
  cpuinfo,懂的看 ;)
  processor: 63
  vendor_id: GenuineIntel
  cpu family: 6
  model: 79
  model name: Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.10GHz
  stepping: 1
  microcode: 0xb000021
  cpu MHz: 1200.219
  cache size: 40960 KB
  physical id: 1
  siblings: 32
  core id: 15
  cpu cores: 16
  apicid: 63
  initial apicid: 63
  fpu: yes
  fpu_exception: yes
  cpuid level: 20
  wp: yes
  flags: fpu vme de …
  bugs:
  bogomips: 4201.09
  clflush size: 64
  cache_alignment: 64
  address sizes: 46 bits physical, 48 bits virtual
  power management:
  关于FreeSWITCH视频会议相关的技术,很久以前在易灵微课上讲过一次课:《是的,我们在做视频会议》,欢迎阅读。
  烟台小樱桃科技是FreeSWITCH开源项目的核心贡献者,文中提到了很多补丁都已提交到FreeSWITCH的源代码仓库。
  烟台小樱桃科技招聘FreeSWITCH相关开发及运维实施人员,如果有兴趣加入我们,欢迎发邮件到 jobs@x-y-t.cn。
  烟台小樱桃科技提供专业的FreeSWITCH技术支持及爱博体育赞助巴塞中心解决方案。欢迎参观,邮件info@x-y-t.cn。
  另外,我们将于11月22日在北京搞事情,欢迎参加:第八届FreeSWITCH-CN开发者沙龙
  如果您对具体的技术感兴趣,也欢迎参加我们的FreeSWITCH培训:FreeSWITCH高级培训冬季班-北京站
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

专题

各大党政科技媒体争相报道亿联网络
各大党政科技媒体...
各大党政科技媒体争相报道亿联网络 [详细]
小i智慧学堂
小i智慧学堂
  小i智慧学堂是一个AI应用人才培养与发展平台,致力...[详细]
北京InfoComm China 2019
北京InfoComm Ch...
  一年一度专业视听和集成体验行业盛会北京InfoComm ...[详细]
2019可信云大会在京召开
2019可信云大会在...
  7月2日,由中国信息通信研究院主办、中国IDC圈协办...[详细]

CTI论坛会员企业