技术背景

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

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

(相关资料图)

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

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

方案比较

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

如何开启轻量级RTSP组播？

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

点击“发布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的同屏技术方案，大概设计如下：

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的，现场反馈非常不错。