面向内网无纸化会议/智慧教室/实时同屏,组播还是RTMP?

简介:

一、背景

为满足内网无纸化/电子教室等内网超低延迟需求,避免让用户配置单独的服务器,我们研发了轻量级RTSP服务开发包。

单播不再赘述,这里重点介绍下我们的组播技术方案:

组播解决的主要痛点是服务器部署和带宽占用问题,一般来说,内网电子教室/无纸化/实时同屏场景用RTMP推送+RTMP服务器,然后其他端从服务器拉取RTMP流,这个方案的劣势在于,如果单独部署服务器,需要额外的机器,增加了成本开销,如果教师端机器作为服务器,网络和机器性能双重压力下,负荷过重。

通过组播技术方案,只要网络设备支持组播组网,轻松实现多并发的同屏/摄像头直播场景。

但是,组播的劣势在于,高码率的无线网络环境体验很差,也就是说,如果是Windows或者Android平台推送,Android无线PAD播放,真正好用的,还是RTMP推拉流技术解决方案。

二、基于组播的技术方案

  1. 设置需要共享的视音频,设置码率后,点击“配置查看Rtsp服务”,选中“组播”和“SSM”选项,点击启动服务即可:

image

  1. 确定后,返回主界面,点击“发布Rtsp流”,拷贝回调的RTSP url,用我们的SmartPlayer.exe或移动端播放器,播放即可。

image

注意:需要内网网络设备支持组播功能。

经长时间测试,毫秒级延迟,完全满足内网同屏技术指标。

内置RTSP服务核心接口(以Windows C++ 接口为例:nt_smart_publisher_sdk.h):



        /*
        * 创建一个rtsp server 
        * pRtspServerHandle: rtsp server 句柄
        * reserve:保留参数传0
        * 成功返回 NT_ERC_OK
        */
        NT_UINT32(NT_API *OpenRtspServer)(NT_PHANDLE pRtspServerHandle, NT_INT32 reserve);

        /*
        * 设置rtsp server 监听端口, 在StartRtspServer之前必须要设置端口
        * rtsp_server_handle: rtsp server 句柄
        * port: 端口号,可以设置为554,或者是1024到65535之间,其他值返回失败
        * 成功返回 NT_ERC_OK
        */
        NT_UINT32(NT_API *SetRtspServerPort)(NT_HANDLE rtsp_server_handle, NT_INT32 port);

        /*
        * 设置rtsp server 鉴权用户名和密码, 这个可以不设置,只有需要鉴权的再设置
        * rtsp_server_handle: rtsp server 句柄
        * user_name: 用户名,必须是英文
        * password:密码,必须是英文
        * 成功返回 NT_ERC_OK
        */
        NT_UINT32(NT_API *SetRtspServerUserNamePassword)(NT_HANDLE rtsp_server_handle, NT_PCSTR user_name, NT_PCSTR password);


        /*
        * 设置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);


        /*
        * 获取rtsp server当前的客户会话数, 这个接口必须在StartRtspServer之后再调用
        * rtsp_server_handle: rtsp server 句柄
        * session_numbers: 会话数
        * 成功返回 NT_ERC_OK
        */
        NT_UINT32(NT_API *GetRtspServerClientSessionNumbers)(NT_HANDLE rtsp_server_handle, NT_INT32* session_numbers);


        /*
        * 启动rtsp server
        * rtsp_server_handle: rtsp server 句柄
        * reserve: 保留参数传0
        * 成功返回 NT_ERC_OK
        */
        NT_UINT32(NT_API *StartRtspServer)(NT_HANDLE rtsp_server_handle, NT_INT32 reserve);

        /*
        * 停止rtsp server
        * rtsp_server_handle: rtsp server 句柄
        * 成功返回 NT_ERC_OK
        */
        NT_UINT32(NT_API *StopRtspServer)(NT_HANDLE rtsp_server_handle);

        /*
        * 关闭rtsp server
        * 调用这个接口之后rtsp_server_handle失效,
        * 成功返回 NT_ERC_OK
        */
        NT_UINT32 (NT_API *CloseRtspServer)(NT_HANDLE rtsp_server_handle);


        /*---rtsp server操作接口---*/

三、基于RTMP的技术方案

​​
image

注意事项

  1. 组网:无线组网,需要好的AP模块才能撑得住大的并发流量,推送端到AP,最好是有线网链接;
  2. 服务器部署:如果Windows平台,可以考虑NGINX,如果是Linux,可以考虑SRS或NGINX,服务器可以和Windows平台的教师机部署在一台机器;
  3. 教师端:如教师有移动的PAD,可以直接推到RTMP服务器,然后共享出去;
  4. 学生端:直接拉取RTMP流播放即可;
  5. 教师和学生互动:学生端如需作为示范案例,屏幕数据共享给其他同学,只需请求同屏,数据反推到RTMP服务器,其他学生查看即可。
  6. 扩展监控:如果需要更进一步的技术方案,如教师端想监控学生端的屏幕情况,可以有两种方案,如学生端直接推RTMP过来,或者,学生端启动内置RTSP服务,教师端想看的时候,随时看即可(亦可轮询播放)。

RTMP延迟大,这种说法,相对片面,好多是由于推拉流模块本身问题导致(如果服务器系NIGNX或SRS,基本可排除服务器转发导致的大时延,不要再赖服务器了),从我们官方和实际场景来看,RTMP整体技术方案,延迟可做到1秒内,毫秒级。

目录
相关文章
|
数据采集 编解码 监控
Android对接实现内网无纸化会议|智慧教室|实时同屏功能
本文主要讲的是基于Android平台实现RTMP的技术方案设计,基础架构图如下:
121 0
Android对接实现内网无纸化会议|智慧教室|实时同屏功能
|
5月前
|
网络性能优化 定位技术 C++
跨地区远程访问如何更快、更稳、更可靠:贝锐蒲公英智能选路
贝锐蒲公英云智慧组网采用自研智能选路技术,可根据实时网络状况自动选择最优路径,大幅降低延迟并提升传输速率。相较于传统单线模式下数据必须经由单一服务器转发导致高延迟与无备份线路的问题,蒲公英通过全球分布式节点与SD-WAN技术实现了智能实时导航能力。实测显示,智能选路可使通讯延迟降低5倍、传输速率提升百倍。该技术基于多云服务商的主干网络与FullMesh架构,能自动避开拥堵路径并确保网络可用性,即使面对线路故障也能自动切换,提供更快速、稳定和可靠的跨地区远程访问体验。
114 3
跨地区远程访问如何更快、更稳、更可靠:贝锐蒲公英智能选路
|
编解码 开发工具 数据安全/隐私保护
内网无纸化会议/智慧教室实时同屏RTSP组播技术方案思考
内网环境下,为了满足内网无纸化/电子教室等内网超低延迟需求,避免让用户配置单独的服务器,好多开发者希望有RTSP的技术方案,用于小并发场景,特别是在组网环境好的有线环境下,使用RTSP服务配合组播,是也是好多开发者考量的因素之一。
187 2
|
Web App开发 网络协议 API
干货满满:多人语音聊天室源码开发解析
目前,一对一直播源码平台已经不能满足广大社交场景和人群了,而多人语音聊天室源码的开发属性,正好满足此需求,也让社交更加多样化、娱乐化,那么在技术上如何开发多人语音聊天室源码呢?
干货满满:多人语音聊天室源码开发解析
|
编解码 开发工具 Android开发
【技术分享】无纸化会议|智慧教室同屏走RTSP组播还是RTMP?
我们在做内网多人同屏(比如无纸化会议、智慧教室同屏)技术方案的时候,遇到个问题:到底使用轻量级RTSP服务实现组播,还是基于RTMP的解决方案?
231 0
|
编解码 监控 应用服务中间件
基于智慧教室|无纸化会议的新选择:RTMP解决方案
基于智慧教室或是会议的技术方案,一般主要是涉及到屏幕采集和推送,整体技术方案这块,一般建议走RTMP,说到这里,好人开发者提到,市面上也有RTSP的技术方案,甚至RTSP组播方案,这块,大牛直播SDK Github 也做过相关对比,总的来说60人智慧教室或类似同屏场景下,最可靠的还是RTMP的解决方案(不赘述,具体可自行测试对比)。
120 0
SIP的voip语音环境咬线或摘机状态什么处理
SIP的voip语音环境咬线或摘机状态什么处理
|
Web App开发 网络虚拟化
使用 WebRTC 构建简单的视频聊天室(1)
使用 WebRTC 构建简单的视频聊天室(1)
425 0
|
存储 搜索推荐 安全
迅时IP-PBX电话系统特色功能应用
本文以OM80E为例,简要介绍迅时IP-PBX的五大特色应用。 - 企业直线电话 - 录音管理 - 商务电话管家 - 外网分机注册 - 呼叫中心集成
|
语音技术
迅时IP-PBX电话交换机制作来电欢迎词
欢迎词是给来电客户的第一印象,一段好的来电欢迎词不仅能够体现公司形象,也能够提高接听效率,一举多得。