大牛直播SDK

简单来说，之前推送端SDK支持的功能，内置轻量级RTSP服务SDK后，功能继续支持，并实现了从单一RTMP音视频数据推送到多元本地服务供给的关键跨越，全方位契合用户于内网场景下不断衍生的多样化诉求。的场景，支持H.264/H.265，支持RTSP鉴权、单播、组播模式，考虑到单个服务承载能力，我们支持同时创建多个RTSP服务，并支持获取当前RTSP服务会话连接数。，实现本地的音视频数据（如摄像头、麦克风），编码后，汇聚到内置RTSP服务，对外提供可供拉流的RTSP URL，轻量级RTSP服务

Windows平台如果对延迟和资源占有等，要求非常高，可以选择合适的低延迟RTSP或RTMP播放插件、优化播放参数设置、优化网络环境、优化代码和渲染流程。流播放之前，做好参数配置，如缓冲设置、解码模式、低延迟模式、网络协议设置等播放参数。感兴趣的开发者，可以单独跟我沟通探讨。

GB28181 的补录功能是一种用于弥补视频数据缺失的重要机制。在实际的视频监控场景中，由于网络不稳定、设备故障等多种因素，可能会导致视频数据在上云或存储过程中出现缺失，无法保证数据的完整性。GB28181 的补录功能就是为了解决这一问题而设计的，其目的是在数据缺失后，通过特定的机制拉取缺失时间段的本地录像，以补齐云端或存储系统中的视频数据。：系统会实时监测视频流上云或传输的状态，一旦发现视频流中断，立即标记通道信息和中断时间点。

Android平台实现屏幕采集、音频播放声音采集、麦克风采集编码打包推送到RTMP和轻量级RTSP服务整体流程非常清晰，所以说，如果只是技术学习，很容易打通并实现相关推流demo，如果是要实现高稳定低延迟的同屏系统，还需要有配套好的RTMP、RTSP直播播放器，整体部署，内网大并发环境下，还需要考虑到如何组网等诸多因素。感兴趣的开发者，可以单独跟我沟通探讨。

Android平台内网RTSP网关模块，系内置轻量级RTSP服务模块扩展，完成外部RTSP/RTMP数据拉取并注入到轻量级RTSP服务模块工作，多个内网客户端直接访问内网轻量级RTSP服务获取公网数据，无需部署单独的服务器，支持RTSP/RTMP H.265数据接入。内置轻量级RTSP服务模块和内置RTSP网关模块，核心痛点是避免用户或者开发者单独部署RTSP或者RTMP服务，数据汇聚到内置RTSP服务，对外提供可供拉流的RTSP URL，适用于内网环境下，对并发要求不高。

总之，使用函数可以方便地进行 Windows 平台上的多屏采集。通过定义回调函数并结合其他 Windows API 函数，可以获取监视器信息并进行屏幕采集等操作。在使用过程中，需要注意权限、性能和兼容性等问题。配合大牛直播SDK的推送模块，可以轻松实现Windows平台下的多屏幕采集功能逻辑。

从我发的Android平台RTSP转RTMP推送的demo界面，可以看到，这个demo，不是单纯的RTSP转RTMP推送的，还可以实现RTSP流获取后，回调上来解码后的数据，然后添加动态水印或其他处理后，把video数据二次编码推送出去。或者audio数据二次处理。RTSP转RTMP推送，好多开发者第一想到的是采用ffmpeg命令行的形式，如果对ffmpeg比较熟，而且产品不要额外的定制和更高阶的要求，未尝不可，如果对产品稳定性、时延、断网重连等有更高的技术诉求，比较好的办法，还是采用我们的技术实现。

做RTSP播放器容易，做个可以稳定用于实际场景的低延迟RTSP播放器，真的非常困难，首先，RTSP协议本身的复杂度，如果不涉及底层协议栈，只是开源的项目编译调试小修小改，遇到问题，很难处理。还有就是网络环境的不确定性，视频解码和播放的复杂性，视频同步问题的复杂性及考虑因素。大多数RTSP的播放都面向直播场景，所以，如果延迟过大，严重影响体验，所以，低延迟是衡量一个好的RTSP播放器非常重要的指标，目前大牛直播SDK的RTSP直播播放延迟比开源播放器更优异，而且长时间运行下，不会造成延迟累积。

Android Camera2 API 是从 Android 5.0（Lollipop）开始引入的，相对Camera API，优势非常明显，如果需要通过Android平台采集视频数据，在设备支持的前提下，建议尽可能用Camera2做数据采集。

介绍了 RTMP 直播推送 SDK、RTMP 直播播放 SDK、RTSP 直播播放 SDK、录像 SDK、转发 SDK、轻量级 RTSP 服务 SDK、SEI 扩展数据发送/接收 SDK。

WebRTC和SRT也都有适用的场景，WebRTC已经非常成熟，SRT实际上我们之前也有做过，只是没有对外发布，以目前我们的经历，能把RTMP推送、RTMP播放、RTSP播放、RTSP转RTMP推送、轻量级RTSP服务和GB28181设备接入模块做到一梯队高水平，属实不易，随着后续音视频需求越来越多，我们也会做相应的调整和跟进，与时俱进，提供更优异的低延迟音视频直播解决方案。

我们实现了Linux平台下的以屏幕采集、摄像头采集、麦克风扬声器采集为数据源的RTMP推送模块、轻量级RTSP服务模块，和RTMP播放器和RTSP播放器模块，并同时覆盖了x86-64架构和aarch64架构。你可以根据命令输出的信息，使用其他 xrandr 命令来设置显示器的分辨率、位置、旋转等参数，实现个性化的多显示器设置。它可以让你了解当前的显示器布局，以便更好地进行配置和调整。例如，如果你连接了多个显示器，这个命令可以帮助你确定哪些显示器是处于活动状态的，以及它们的具体配置。

Android平台GB28181接入SDK（SmartGBD），可实现不具备国标音视频能力的 Android终端，通过平台注册接入到现有的GB/T28181—2016服务，可用于如执法记录仪、智能安全帽、智能监控、智慧零售、智慧教育、远程办公、明厨亮灶、智慧交通、智慧工地、雪亮工程、平安乡村、生产运输、车载终端等场景，可能是业内为数不多功能齐全性能优异的商业级水准GB28181接入SDK。但它的延迟同样较高，不适用于实时交互场景，且由于较新，某些设备和浏览器可能不支持该协议。

实时共享屏幕的方法有很多种，用户可以根据自己的需求和实际情况选择最适合的方式。无论是无线投屏、第三方应用、HDMI线连接还是即时通讯软件的屏幕共享功能，都能轻松实现屏幕内容的实时共享。

笔者十几年前从事RTSP播放器底层开发的时候，被同事嗤之以鼻，说在做一个即将被时代抛弃的东西，hls、dash等才是行业发展的主流，十几年过去了，RTSP协议宝刀未老，在各行各业，依然扮演着重要的角色。

实现一个完整的轻量级RTSP服务是一个相对复杂的任务，需要对音视频处理、网络编程和RTSP协议有深入的理解。好多开发者，对我们Android平台轻量级RTSP服务模块有些陌生，不知道这个模块具体适用于怎样的场景，有什么优缺点，实际上，我们的Android平台轻量级RTSP服务模块更适用于内网环境下、对并发要求不高的场景，实现低成本、低延迟的音视频实时传输。：在这些环境中，需要实现音视频的低延迟传输，而轻量级RTSP服务能够避免单独部署RTSP或RTMP服务器，简化部署流程，同时满足对并发要求不高的场景。

Android上实现RTSP服务器是一个极具挑战的任务，功能设计这块，除了需要支持接编码前音视频数据外，还需要支持对接编码后音视频数据，并实现本地录像、快照等功能组合使用。需要注意的是，就像海康、大华的摄像头一样，对外的并发，一般限于4-8个，Android设备的性能一般来说，可能不足以处理高负载的RTSP服务器，但是小并发模式下，能稳定的运行，就达到设计初衷了。

智慧人居市场具有广阔的发展前景和投资机会。随着技术的不断进步和应用场景的拓展，市场规模有望进一步增长。智慧人居的实现方式也多种多样，如智能家居系统，通过智能家居系统，居民可以远程操控家中的照明、空调、安防等设备，并实现自动化控制。智能安防系统，通过人脸识别、行为分析等技术，实现对城市的安全监控和预警。智能环境监测系统，通过传感器和数据分析技术，实时监测城市的空气质量、噪音水平、温湿度等环境指标。智能能源管理系统，通过智能电网技术，实现对能源的智能监测、优化调度和分配管理。

智慧教室无纸化方案在教育、企业培训、科研机构和公共服务等多个领域都得到了广泛应用，并发挥了重要作用。随着技术的不断进步和应用场景的不断拓展，其应用前景将更加广阔。其实一个好的智慧教室无纸化同屏系统，需要考虑组网、分辨率、码率、时延、音视频同步和连续性等各个指标。

废话不多说，先列二者功能：1. Spydroid：The stream can be directly read by VLC which is great because VLC is a very powerful tool, for exampleyou can really easily record the stream in a file. [FAQ See the FAQ ...

为满足内网无纸化/电子教室等内网超低延迟需求，避免让用户配置单独的服务器，大牛直播SDK在推送端发布了轻量级RTSP服务SDK。内置轻量级RTSP服务后，延迟更低，体验更好(内网环境下，200-400毫秒)。 涉及相关库：libSmartPublisher.so 头文件：SmartPlayerJniV2.java SmartPublisherJniV2.java Ja...

好多开发者一直搞不清轻量级RTSP服务SDK和RTSP推流SDK的区别（Github下载地址），以下是相关区别：1. 轻量级RTSP服务模块：轻量级RTSP服务解决的核心痛点是避免用户或者开发者单独部署RTSP或者RTMP服务，实现本地的音视频数据（如摄像头、麦克风），编码后，汇聚到内置RTSP服务，对外提供可供拉流的RTSP URL，轻量级RTSP服务，适用于内网环境下，对并发要求不高的...

很多开发者在做Android平台RTMP推流或轻量级RTSP服务（摄像头或同屏）时，总感觉接口不够用，以大牛直播SDK为例 (Github) 我们来总结下，我们常规需要支持的编码前音视频数据有哪些类型：1. Android摄像头前后camera通过OnPreviewFrame()回调的数据接口： @Override public void onPreviewFrame(byte[] data, Camera camera) { frameCount++;

为什么要设计轻量级RTSP服务轻量级RTSP服务解决的核心痛点是避免用户或者开发者单独部署RTSP或者RTMP服务。轻量级RTSP服务可满足内网无纸化/电子教室等内网超低延迟的低并发需求，避免让用户配置单独的服务器，大牛直播SDK在推送端发布了轻量级RTSP服务模块。设计架构图实现本地的音视频数据（如摄像头、麦克风），编码后，汇聚到内置RTSP服务，对外提供可供拉流的RTSP ...

为满足内网无纸化/电子教室等内网超低延迟需求，避免让用户配置单独的服务器，大牛直播SDK在推送端发布了轻量级RTSP服务SDK：简单来说，之前推送端SDK支持的功能，内置轻量级RTSP服务SDK后，功能继续支持。一、支持功能如不单独说明，系Windows、Android、iOS全平台支持。[基础功能]支持Windows/Android/iOS平台RTMP直播SDK除推送RTMP外...

好多开发者在做虚拟仿真、VR教育等场景的时候，遇到个问题，想把头显里面的画面在内网环境下低延迟的同步出来，又不想单独部署流媒体服务器。上图展示的是，Android的Unity下Camera场景获取到texture数据编码后，注入RTSP服务和RTMP推送模块。轻量级RTSP服务，由于不需要单独部署流媒体服务器，在内网小并发场景下，使用起来非常方便，感兴趣的开发者可酌情参考。由于我们原生Android平台轻量级RTSP服务已经有多年积累，本次只是把相关的接口，同步过来。

最近发现好多开发者都在搜索可用的RTSP测试URL，目前公网实际可测试的RTSP URL非常少，即便是可用，分辨率和网络也非常差，不适合长期测试。针对此，我们的建议是最好直接网上买个海康或大华的摄像头，一般来说，海康大华的RTSP URL格式如下：海康摄像头RTSP URL规则主码流：rtsp://admin:daniulive12345@192.168.0.120:554/h265/ch1/main/av_stream子码流：rtsp://admin:daniulive12345@192.

为什么要设计轻量级RTSP服务首先声明一点，本blog提到的轻量级RTSP服务，类似于网络摄像头（IPC），而非传统意义的接受外部推流的RTSP服务器。轻量级RTSP服务解决的核心痛点：避免用户单独部署RTSP或者RTMP服务，实现本地的音视频数据（如摄像头|屏幕、麦克风），编码后，汇聚到内置RTSP服务，对外提供可供拉流的RTSP URL，轻量级RTSP服务，适用于内网环境下，对并发要求不高的场景，视频编码支持H.264/H.265，音频对外输出AAC，支持RTSP鉴权、单播、组播模式，考虑到单个

背景大家在做Windows平台RTMP推送或轻量级RTSP服务的时候，不管是采集屏幕还是采集摄像头，亦或屏幕摄像头的叠加模式，总会有这样的诉求，采集到的数据，希望能本地看看具体采集的数据或者图像实际效果，也就是本次介绍的“预览”功能。废话不多说，想上图：如何实现开始预览开始预览，大概的流程是，调用OpenPublisherHandle()，进行初始的数据源类型设置，然后调用Open()接口，获取推送handler，并设置event回调。bool CSmartPublisherD

好多开发者疑惑，什么是内置RTSP网关，和轻量级RTSP服务又有什么区别和联系？本文就以上问题，做个简单的介绍：轻量级RTSP服务为满足内网无纸化/电子教室等内网超低延迟需求，避免让用户配置单独的服务器，大牛直播SDK(Github)在推送端发布了轻量级RTSP服务SDK：简单来说，之前推送端SDK支持的功能，内置轻量级RTSP服务SDK后，功能继续支持。轻量级RTSP服务解决的核心痛点是避免用户或者开发者单独部署RTSP或者RTMP服务，实现本地的音视频数据（如摄像头、麦克风），编码后，汇

内网RTSP网关，在小并发的环境下，不需要单独部署RTSP或RTMP服务，配合我们RTSP播放器，延迟毫秒级，优势非常明显，感兴趣的开发者可参考，如果需要测试，可测试看看。

轻量级RTSP服务模块是一个跨平台的、简单易用的 RTSP 服务开发工具包，可以帮助开发者快速实现 RTSP 服务，并且提供多种音视频处理和安全性保障功能，无需单独部署RTSP服务，在内网环境特别是移动端，非常方便。

内网RTSP网关，是轻量级RTSP服务的扩展，配合RTSP播放器，延迟依然毫秒级，通过拉模式，实现了RTMP或RTSP流数据到轻量级RTSP服务的二次转发，优势非常明显。

Linux平台轻量级RTSP服务，对我们来说，轻车熟路了，主要是demo展示这块，整体编码性能和延迟，配合我们的RTSP播放器测试下来，几百毫秒，可完全满足无纸化同屏、教育类等传统行业技术诉求。

Unity下的“多端同屏”云渲染以及相关可视化平台解决方案，成为助力了工业领域数字化转型。除上述场景外，还需要考虑多实例多camera模式，实现高效率低延迟和低资源占有的互动体验。

轻量级RTSP服务和RTMP推送的区别在于，轻量级RTSP服务不需要单独部署流媒体服务器（类似于网络摄像头），在内网小并发场景下，使用起来非常方便，如果需要上公网，还是需要用RTMP推送，感兴趣的开发者可酌情参考。

需要注意的是，无论是轻量级RTSP服务还是RTMP推送设计，因为是通过H.264扩展SEI发送和接收自定义数据，会存在数据或消息丢失的情况，很难实现可靠传输，当然，也可以在多帧数据携带数据，确保消息多次重传达到防止部分数据丢失的目的。

以上是大概的流程，从RTSP拉流到数据处理后，重新塞给轻量级RTSP服务，然后播放端再从轻量级RTSP服务端拉流，如果针对YUV或RGB算法处理延迟不大的话，整体延迟可轻松达到毫秒级，满足大多数场景的技术诉求。

RTSP拉流二次编码，整体逻辑不复杂，就是把数据回调后，二次处理，我们推送端设计的是图层的形式，所以，回调后的数据，直接作为第0层，文字水印作为第一层，如果需要图片水印，图片水印作为第三层即可。RTSP拉流二次编码，如果做到客户端尽量无感知，需要尽可能的压缩整体处理的延迟，确保从数据采集，到二次处理，到再次播放出来毫秒级，满足绝大多数场景下的技术需求。

Unity平台下RTMP推送、录像、轻量级RTSP服务，在虚拟仿真、医疗、教育等场景下，应用非常广泛。要实现低延迟，除了需要高效率的音视频数据采集，编码和数据投递外，还需要好的直播播放器支持。配合我们的SmartPlayer，可轻松实现毫秒级体验，满足绝大多数应用场景技术诉求。