【技术分享】无纸化会议|智慧教室同屏走RTSP组播还是RTMP?

简介: 我们在做内网多人同屏(比如无纸化会议、智慧教室同屏)技术方案的时候,遇到个问题:到底使用轻量级RTSP服务实现组播,还是基于RTMP的解决方案?

技术背景

我们在做内网多人同屏(比如无纸化会议、智慧教室同屏)技术方案的时候,遇到个问题:到底使用轻量级RTSP服务实现组播,还是基于RTMP的解决方案?


先说为什么大家喜欢组播吧:


组播技术方案,大家第一件事想到的就是服务器部署和带宽问题,直接教师端或者主讲人机器,启动个轻量级的RTSP服务,然后开个组播选项,看起来一切问题迎刃而解。


为什么好多人排斥RTMP的技术方案呢?大概是觉得,RTMP的延迟控制做的不好,影响体验,还有就是,觉得单独部署个RTMP服务,耗费多余的资源。

方案比较

先说轻量级RTSP组播方案吧,实际上,大牛直播SDK做轻量级RTSP服务的时候,也支持组播设置。


如何开启轻量级RTSP组播?


以windows平台为例,点击“配置查看Rtsp服务”,选中“组播”和“SSM”选项,点击启动服务即可:

0ede37305927431682804030e699c04a.png

点击“发布RTSP流”按钮后,会在播放地址里面,回调上来拉流的RTSP URL,经长时间测试,毫秒级延迟,完全满足内网同屏技术指标。但需要注意的是,开启组播的话,需要内网网络设备支持组播功能。组播的劣势在于,高码率的无线网络环境下,体验比较差,组网优先级过低


轻量级RTSP服务,对应的组播接口选项如下:

   /*
    * nt_smart_publisher_sdk.h
    * Author: daniusdk.com
    */    
   /*
    * 设置rtsp server 组播, 如果server设置成组播就不能单播,组播和单播只能选一个, 一般来说单播网络设备支持的好,wifi组播很多路由器不支持
    * rtsp_server_handle: rtsp server 句柄
    * is_multicast: 是否组播, 1为组播, 0为单播, 其他值接口返回错误, 默认是单播
    * 成功返回 NT_ERC_OK
    */
    NT_UINT32(NT_API *SetRtspServerMulticast)(NT_HANDLE rtsp_server_handle, NT_INT32 is_multicast);
    /*
    * 设置rtsp server 组播组播地址 
    * rtsp_server_handle: rtsp server 句柄
    * multicast_address: 组播地址
    * 如果设置的不是组播地址, 将返回错误
    * 组播地址范围说明: [224.0.0.0, 224.0.0.255] 为组播预留地址, 不能设置. 可设置范围为[224.0.1.0, 239.255.255.255], 其中SSM地址范围为[232.0.0.0, 232.255.255.255]
    * 成功返回 NT_ERC_OK
    */
    NT_UINT32(NT_API *SetRtspServerMulticastAddress)(NT_HANDLE rtsp_server_handle, NT_PCSTR multicast_address);

下面,我们来聊聊基于RTMP的同屏技术方案,大概设计如下:

aad0124a480f4367b4151937a368036f.png

1. 组网无线组网,需要好的AP模块才能撑得住大的并发流量,推送端到AP,最好是有线网链接;


2. 服务器部署:可用业内非常稳定的比如nginx或SRS服务,如果用windows的RTMP服务器,可以考虑和Windows平台的教师机部署在一台机器(教师机连有线网);


3. 教师端(主讲人):如教师有移动的PAD,可以直接推到RTMP服务器,然后共享出去;


4. 学生端(观众):无论windows电脑还是android pad,直接拉取RTMP流播放即可;


5. 教师(主讲人)和学生(观众)互动:学生端如需作为示范案例,屏幕数据共享给其他同学,只需请求同屏,数据反推到RTMP服务器,其他学生查看即可。


6. 轮询监控:如果需要更进一步的技术方案,如教师端想监控学生端的屏幕情况,可以有两种方案,如学生端直接推RTMP过来,或者,学生端启动内置RTSP服务,教师端想看的时候,随时看即可。

RTMP技术方案功能设计

功能设计,我们分主讲人和观看端来列,我们目前已支持Windows、Linux(x86_64)、Android和iOS平台,由于我们是做的通用的推拉流模块,功能支持,非常全,如果只是特定项目需求自研的话,没必要做的这么复杂。


教师端(主讲人):

  • [本地预览]Windows平台支持摄像头/屏幕/合成数据实时预览功能,Android/iOS平台支持本地前后置摄像头预览;
  • [摄像头反转/旋转]Windows平台支持摄像头水平反转、垂直反转、0°/90°/180°/270°旋转;
  • [摄像头采集]除常规YUV格式外,Windows平台还支持MJPEG格式的摄像头采集;
  • [麦克风/扬声器采集]Windows平台音频输入端支持麦克风、扬声器,或麦克风和扬声器混音输入;
  • [RTMP推流]超低延时的RTMP协议直播推流SDK(Windows/Android/iOS支持RTMP扩展H.265推送);
  • [视频格式]Windows/Android平台支持H.264/H.265编码(Android H.265硬编码),iOS平台支持H.264编码;
  • [音频格式]Windows/Android/iOS平台支持AAC编码,Windows/Android平台支持Speex编码;
  • [音频编码]Windows/Android平台支持Speex推送、Speex编码质量设置;
  • [音量调节]Windows/Android平台采集端支持实时音量调节(其中,Windows平台混音模式下支持单独控制麦克风、扬声器音量);
  • [H.264硬编码]Windows/Android/iOS平台支持H.264特定机型硬编码;
  • [H.265硬编码]Android/iOS平台支持H.265特定机型硬编码;
  • [硬编码自适应]Android/iOS平台支持硬编码自适应,如检测到硬编码不支持,自动切换到软编(iOS如H.265硬编,先切换到H.264硬编码,如不支持再尝试H.264软编);
  • [软硬编码参数配置]支持gop间隔、帧率、bit-rate设置;
  • [软编码参数配置]支持软编码profile、软编码速度、可变码率设置;
  • [多实例推送]支持多实例推送(如同时推送屏幕/摄像头和外部数据);
  • [RTMP扩展H.265]Windows/Android/iOS推送SDK支持RTMP扩展H.265推送,Windows针对摄像头采集软编码,使用H.265可变码率,带宽大幅节省,效果直逼传统H.265编码摄像头,Android/iOS平台支持H.265硬编码;
  • [横竖屏推流]Android/iOS平台支持支持横屏、竖屏推流;
  • [多分辨率支持]支持摄像头或屏幕多种分辨率设置;
  • [Windows推屏]Windows平台支持屏幕裁剪、窗口采集、屏幕/摄像头数据合成等多种模式推送;
  • [移动端推屏]Android平台支持后台service推送屏幕(推送屏幕需要5.0+版本);
  • [移动端推屏]iOS平台支持后台推送屏幕(基于ReplayKit,需要iOS 10.0+版本);
  • [事件回调]支持各种状态实时回调;
  • [水印]Windows平台支持文字水印、png水印、实时遮挡,Android平台支持文字水印、png水印;
  • [RTMP推送模式]支持RTMP推送 live|record模式设置(需服务器支持);
  • [镜像]Android/iOS平台支持前置摄像头实时镜像功能;
  • [前后摄像头实时切换]Android/iOS平台支持采集过程中,前后摄像头切换;
  • [复杂网络处理]支持断网重连等各种网络环境自动适配;
  • [动态码率]支持根据网络情况自动调整推流码率;
  • [实时静音]支持推送过程中,实时静音/取消静音;
  • [实时快照]支持推流过程中,实时快照;
  • [纯音频推流]支持仅采集音频流并发起推流功能;
  • [纯视频推流]支持特殊场景下的纯视频推流功能;
  • [降噪]Windows/Android平台支持环境音、手机干扰等引起的噪音降噪处理、自动增益、VAD检测;
  • [回音消除]Android平台支持实时传递远端PCM数据,方便回音消除处理;
  • [外部编码前视频数据对接]支持YUV数据对接;
  • [外部编码前音频数据对接]支持PCM对接;
  • [外部编码后视频数据对接]支持外部H.264数据对接;
  • [外部编码后音频数据对接]外部AAC/PCMA/PCMU/SPEEX数据对接;
  • [推送端休眠设置]Windows平台支持休眠接口(设置成休眠模式后CPU会适当降低);
  • [编码后数据输出]Android平台支持输出编码后的H264/AAC数据到上层,方便对接第三方平台(如GB28181)对接;
  • [扩展录像功能]完美支持和录像SDK组合使用,录像相关功能,可参见”Windows/Android/iOS录像SDK“;
  • [裁剪模式]Android/iOS平台支持特定分辨率摄像头裁剪模式设置;
  • [服务器兼容]支持自建服务器(如Nginx、SRS)或CDN。


学生(观看端):

  • [多实例播放]支持多实例播放;
  • [事件回调]支持网络状态、buffer状态等回调;
  • [视频格式]支持RTMP扩展H.265,H.264;
  • [音频格式]支持AAC/PCMA/PCMU/Speex;
  • [H.264/H.265软解码]支持H.264/H.265软解;
  • [H.264硬解码]Windows/Android/iOS支持特定机型H.264硬解;
  • [H.265硬解]Windows/Android/iOS支持特定机型H.265硬解;
  • [H.264/H.265硬解码]Android支持设置Surface模式硬解和普通模式硬解码;
  • [缓冲时间设置]支持buffer time设置;
  • [首屏秒开]支持首屏秒开模式;
  • [低延迟模式]支持低延迟模式设置(公网200~400ms);
  • [复杂网络处理]支持断网重连等各种网络环境自动适配;
  • [快速切换URL]支持播放过程中,快速切换其他URL,内容切换更快;
  • [音视频多种render机制]Android平台,视频:SurfaceView/GLSurfaceView,音频:AudioTrack/OpenSL ES;
  • [实时静音]支持播放过程中,实时静音/取消静音;
  • [实时音量调节]支持播放过程中实时调节音量;
  • [实时快照]支持播放过程中截取当前播放画面;
  • [只播关键帧]Windows平台支持实时设置是否只播放关键帧;
  • [渲染角度]支持0°,90°,180°和270°四个视频画面渲染角度设置;
  • [渲染镜像]支持水平反转、垂直反转模式设置;
  • [等比例缩放]支持图像等比例缩放绘制(Android设置surface模式硬解模式不支持);
  • [实时下载速度更新]支持当前下载速度实时回调(支持设置回调时间间隔);
  • [ARGB叠加]Windows平台支持ARGB图像叠加到显示视频;
  • [解码前视频数据回调]支持H.264/H.265数据回调;
  • [解码后视频数据回调]支持解码后YUV/RGB数据回调;
  • [解码后视频数据缩放回调]Windows平台支持指定回调图像大小的接口(可以对原视图像缩放后再回调到上层);
  • [解码前音频数据回调]支持AAC/PCMA/PCMU/SPEEX数据回调;
  • [音视频自适应]支持播放过程中,音视频信息改变后自适应;
  • [扩展录像功能]支持拉流端录像。

技术总结

基于轻量级RTSP服务的组播方案一定好吗?


我们觉得不一定,组播对组网提出了要求,而且RTSP本身的设计,就是允许一定的丢包率保持时延的,大家可以实际测试看,不一定有预期的那么好。


如果是小并发场景下,直接启动轻量级RTSP服务,也是个不错的选择,轻量级RTSP服务,本身设计如网络摄像头一样,非常适用于无需单独部署流媒体服务器的场景下。


RTMP的技术方案一定延迟大吗?


这种说法,相对片面,好多是由于推拉流模块本身问题导致(如果服务器系NIGNX或SRS,基本可排除服务器转发导致的大时延),从我们官方和实际场景来看,RTMP整体技术方案,延迟可做到1秒内,毫秒级,目前实际在用的公司中,采用我们技术方案的,大多都是RTMP的,现场反馈非常不错。

相关文章
|
数据采集 编解码 监控
Android对接实现内网无纸化会议|智慧教室|实时同屏功能
本文主要讲的是基于Android平台实现RTMP的技术方案设计,基础架构图如下:
119 0
Android对接实现内网无纸化会议|智慧教室|实时同屏功能
|
3月前
|
Web App开发 网络协议 Android开发
### 惊天对决!Android平台一对一音视频通话方案大比拼:WebRTC VS RTMP VS RTSP,谁才是王者?
【8月更文挑战第14天】随着移动互联网的发展,实时音视频通信已成为移动应用的关键部分。本文对比分析了Android平台上WebRTC、RTMP与RTSP三种主流技术方案。WebRTC提供端到端加密与直接数据传输,适于高质量低延迟通信;RTMP适用于直播场景,但需服务器中转;RTSP支持实时流播放,但在复杂网络下稳定性不及WebRTC。三种方案各有优劣,WebRTC功能强大但集成复杂,RTMP和RTSP实现较简单但需额外编码支持。本文还提供了示例代码以帮助开发者更好地理解和应用这些技术。
148 0
|
6月前
|
数据安全/隐私保护 云计算
视频会议
视频会议
332 2
|
编解码 开发工具 数据安全/隐私保护
内网无纸化会议/智慧教室实时同屏RTSP组播技术方案思考
内网环境下,为了满足内网无纸化/电子教室等内网超低延迟需求,避免让用户配置单独的服务器,好多开发者希望有RTSP的技术方案,用于小并发场景,特别是在组网环境好的有线环境下,使用RTSP服务配合组播,是也是好多开发者考量的因素之一。
181 2
|
Web App开发 网络协议 API
干货满满:多人语音聊天室源码开发解析
目前,一对一直播源码平台已经不能满足广大社交场景和人群了,而多人语音聊天室源码的开发属性,正好满足此需求,也让社交更加多样化、娱乐化,那么在技术上如何开发多人语音聊天室源码呢?
干货满满:多人语音聊天室源码开发解析
|
编解码 监控 应用服务中间件
基于智慧教室|无纸化会议的新选择:RTMP解决方案
基于智慧教室或是会议的技术方案,一般主要是涉及到屏幕采集和推送,整体技术方案这块,一般建议走RTMP,说到这里,好人开发者提到,市面上也有RTSP的技术方案,甚至RTSP组播方案,这块,大牛直播SDK Github 也做过相关对比,总的来说60人智慧教室或类似同屏场景下,最可靠的还是RTMP的解决方案(不赘述,具体可自行测试对比)。
118 0
|
Web App开发 网络虚拟化
使用 WebRTC 构建简单的视频聊天室(1)
使用 WebRTC 构建简单的视频聊天室(1)
423 0
|
Web App开发 移动开发 边缘计算
阿里云李松林:全球实时传输网络GRTN在互动直播中技术实践
2021年6月9日,亚太内容分发大会暨CDN峰会在北京举行,阿里云智能边缘云技术专家李松林受邀参加互动直播论坛,分享基于阿里云边缘云节点打造的全球实时传输网络GRTN的设计思路、技术原理、特质与应用实践,以及面向直播应用客户提供稳定可靠的业务体验。
1428 0
阿里云李松林:全球实时传输网络GRTN在互动直播中技术实践
|
Web App开发 编解码 缓存
基于视频流传输 — 在线教育白板技术
在线教育不同于线下教育, 内容需要经过电子白板展现给用户,如何做出优秀的在线教育白板成为研究的重点。本文来自学而思网校客户端架构负责人赵文杰在 LiveVideoStackCon 2018 大会上的分享,并由 LiveVideoStack 整理而成。
基于视频流传输 — 在线教育白板技术
|
Web App开发 编解码
不需要SFU实现WebRTC联播实践
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/81517933 ...
2758 0