一、背景
为满足内网无纸化/电子教室等内网超低延迟需求，避免让用户配置单独的服务器，我们研发了轻量级RTSP服务开发包。
单播不再赘述，这里重点介绍下我们的组播技术方案：
组播解决的主要痛点是服务器部署和带宽占用问题，一般来说，内网电子教室/无纸化/实时同屏场景用RTMP推送+RTMP服务器，然后其他端从服务器拉取RTMP流，这个方案的劣势在于，如果单独部署服务器，需要额外的机器，增加了成本开销，如果教师端机器作为服务器，网络和机器性能双重压力下，负荷过重。
通过组播技术方案，只要网络设备支持组播组网，轻松实现多并发的同屏/摄像头直播场景。
但是，组播的劣势在于，高码率的无线网络环境体验很差，也就是说，如果是Windows或者Android平台推送，Android无线PAD播放，真正好用的，还是RTMP推拉流技术解决方案。
二、基于组播的技术方案
- 设置需要共享的视音频，设置码率后，点击“配置查看Rtsp服务”，选中“组播”和“SSM”选项，点击启动服务即可：
- 确定后，返回主界面，点击“发布Rtsp流”，拷贝回调的RTSP url，用我们的SmartPlayer.exe或移动端播放器，播放即可。
注意：需要内网网络设备支持组播功能。
经长时间测试，毫秒级延迟，完全满足内网同屏技术指标。
内置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的技术方案
注意事项
- 组网：无线组网，需要好的AP模块才能撑得住大的并发流量，推送端到AP，最好是有线网链接；
- 服务器部署：如果Windows平台，可以考虑NGINX，如果是Linux，可以考虑SRS或NGINX，服务器可以和Windows平台的教师机部署在一台机器；
- 教师端：如教师有移动的PAD，可以直接推到RTMP服务器，然后共享出去；
- 学生端：直接拉取RTMP流播放即可；
- 教师和学生互动：学生端如需作为示范案例，屏幕数据共享给其他同学，只需请求同屏，数据反推到RTMP服务器，其他学生查看即可。
- 扩展监控：如果需要更进一步的技术方案，如教师端想监控学生端的屏幕情况，可以有两种方案，如学生端直接推RTMP过来，或者，学生端启动内置RTSP服务，教师端想看的时候，随时看即可（亦可轮询播放）。
RTMP延迟大，这种说法，相对片面，好多是由于推拉流模块本身问题导致（如果服务器系NIGNX或SRS，基本可排除服务器转发导致的大时延，不要再赖服务器了），从我们官方和实际场景来看，RTMP整体技术方案，延迟可做到1秒内，毫秒级。
