乐学吧

Android平台RTSP、RTMP播放器回调yuv数据，意义非常重大，既保证了低延迟传输解码，又可以通过回调解码后数据，高效率的投递给AI算法，实现视觉处理。ffmpeg实现还是SmartPlayer，各有利弊

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

上述是我们公司的海康摄像头，2560*1440分辨率，25帧，8M码率播放效果，左边是VLC，右边是SmartPlayer大概延迟情况，可以看到，VLC延迟在1.5秒左右，SmartPlayer的在200ms左右。SmartPlayer是大牛直播SDK旗下全自研内核，行业内一致认可的跨平台RTSP直播播放器SDK，功能齐全、高稳定、超低延迟，超低资源占用，适用于安防、教育、单兵指挥等行业。

为什么要选GB28181？好多开发者跟我们做沟通交流的时候，问的比较多的问题是，你们是怎么想到做Android平台GB28181设备接入模块的？为什么有了RTMP推送模块、轻量级RTSP服务模块，还要费时费力的做GB28181设备接入模块？GB28181规范有什么优势或特点？GB28181规范以其标准化、高效的数据传输与控制、广泛的应用场景以及安全防护与标准扩展等技术优势，在视频监控领域发挥着重要作用。

作为公共安全视频监控联网系统的国家标准，GB28181为不同厂家、不同类型的视频监控设备规定了统一的通信标准和技术规范。这使得各种品牌和型号的设备能够轻松实现互联互通，打破了以往设备之间因通信协议差异而形成的信息壁垒。无论是海康、大华等大型安防企业的设备，还是其他小型厂商的产品，只要符合 GB28181 标准，都可以接入到同一个监控网络中，便于统一管理和调度。遵循开放式架构的原则，具有良好的可扩展性，并且与其他相关标准（如 ONVIF、PSI 等）具有一定的兼容性。

如果按照简单的像素数量比例来估算，12K 视频的带宽需求可能是 8K 视频的 1.5 倍左右，实际的带宽需求还会受到视频编码方式、帧率、色彩深度等多种因素的影响。好多开发者，在设置视频编码参数的时候，对不同分辨率的带宽设置，缺乏相关的经验，实际上，视频分辨率与所需带宽之间的关系受到多个因素的影响，包括视频编码方式、帧率、视频内容的动态程度等。而采用更高效的编码标准如 H.265 或 AV1，可能在较低的带宽下也能实现较好的画质，但一般也需要 15Mbps - 30Mbps 的带宽。

实际应用中可能需要根据具体情况进行更多的错误处理、性能优化和功能扩展。此外，还可以根据需要调整模型参数、使用不同的数据集进行训练，并结合其他技术和方法来提高安全帽佩戴检测的准确性和可靠性。在安全帽和工作人员的身份标识上安装 RFID 标签，通过 RFID 读写器检测标签信号来判断安全帽的佩戴状态。安排专人在施工现场等场所进行巡视，观察工作人员是否佩戴安全帽。利用摄像头采集图像，通过图像识别技术判断人员是否佩戴安全帽。在安全帽上安装传感器，通过传感器检测安全帽的佩戴状态。

大牛直播SDK跨平台SmartPublisher RTMP直播推送模块，始于2015年，支持Windows、Linux（x64_64架构|aarch64）、Android、iOS平台，支持采集推送摄像头、屏幕、麦克风、扬声器、编码前、编码后数据对接，功能强大，性能优异，配合大牛直播SDK的SmartPlayer播放器，轻松实现毫秒级的延迟体验，满足大多数行业的使用场景。：用户可以设置无限数量的场景，每个场景可以由多个不同的视频源、图像、文本等组成，并且能够通过自定义转场效果在不同场景之间实现无缝切换。

在之前的blog里面，我们有介绍OpenCV和yolo的区别，本文就人脸检测为例，分别介绍下OpenCV和yolo的实现方式。

总的来说，QUIC 和 RTMP 的结合可以为实时流媒体传输带来一些优势，但也面临一些挑战和限制。在实际应用中，需要根据具体的需求和场景进行评估和选择，以确定是否适合采用这种结合方式。同时，随着技术的不断发展，未来可能会出现更多更好的解决方案来满足实时流媒体传输的需求。

相对于之前的 H.265/HEVC 和 H.264/AVC 视频编码标准，VVC 对 8K 超高清、屏幕、高动态和 360 度全景视频等新的视频类型以及自适应带宽和分辨率的流媒体和实时通信等应用有了更好的支持。目前，我们已经支持了RTMP H.265（包含Enhanced RTMP）和RTSP H.265（H.265硬编、硬解），但从市场反馈来看，特别是RTMP的265，使用率并不是太高。今天我们讨论的是，为什么H.266视频标准都来了，H.265缺为完全普及？

这意味着在编码和解码过程中，需要更强大的硬件设备来支持，否则可能会导致编码和解码的速度较慢，影响视频的实时传输和播放。特别是在高动态范围（HDR）视频的处理上，AV1 具有较好的表现，能够呈现更丰富的色彩和更高的对比度。：由于其成熟的技术和广泛的兼容性，仍然是目前市场上应用最广泛的视频编码标准，几乎所有的视频设备和平台都支持 H.264。：编码复杂度相对较低，对硬件的要求也较低，大多数设备都能够轻松地支持 H.264 的编码和解码，因此具有广泛的兼容性。：编码复杂度同样较高，对硬件的计算能力有较高的要求。

选择 Python还是 C++ 取决于具体的项目需求和应用场景。如果注重开发效率、快速原型设计和丰富的库支持，Python 是一个不错的选择；如果对性能要求极高或需要进行底层控制，C++ 可能更合适。在实际应用中，也可以结合两者的优势，使用 Python进行快速开发和原型设计，然后用 C++ 实现关键的性能瓶颈部分，我们在对接开发者的实时音视频低延迟诉求的时候，会用我们C C++开发的播放器SDK，通过YUV或RGB数据回调的形式，把数据返回到上层，然后上层通过和Python交互，实现数据二次处理。

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

它是专门针对视频监控系统中监控设备间通信而制定的标准，具有很强的规范性和权威性，主要用于保障公共安全领域视频监控系统的互联、互通、互控。支持视频流、音频流和数据流的传输和控制，具有设备注册、设备发现、视频预览、录像回放、报警事件通知和分发、设备控制等功能。：主要应用于大规模的公共安全视频监控联网系统，例如城市安防监控、交通监控、公安监控等场景。：是一种通用的协议，被广泛应用于各种流媒体设备和系统中，但不同厂家的设备在实现 RTSP 协议时可能存在一些差异，导致在某些情况下设备之间的兼容性可能会受到影响。

VLC for Android强调其功能丰富、性能出色、兼容性好等优点，更适合对延迟要求不是很苛刻的点播场景下，SmartPlayer是一个功能强大、性能优异、具有高度可定制性的流媒体播放器，适用于各种对视频播放质量和实时性要求较高的应用场景。：具有超低延迟的特点，在机器性能没有瓶颈的前提下，其 RTSP 播放器和 RTMP 播放器延迟可以达到业内领先的水平，适用于对实时性要求较高的场景，如安防监控、在线教育、互动直播等.

好多开发者，在调研Android平台GB28181实时回传的时候，对这块整体的流程，没有个整体的了解，本文以大牛直播SDK的SmartGBD设计开发为例，聊下如何在Android终端实现GB28181音视频数据实时回传。在发送过程中，需要注意网络状况，对数据进行适当的分包和组包处理，以确保数据的正确传输。：当设备出现故障或异常情况时，如摄像头故障或编码失败，需要及时进行错误处理，并向平台发送相应的错误报告。：当网络出现异常时，如网络断开或连接超时，需要及时进行重连或重新注册等操作，以保证数据的实时回传。

如果C#和Python运行在同一台机器上，可以通过共享内存或文件系统进行数据交换。这种方法相对简单，但性能可能不如前两种方法。使用Flask或Django等Web框架创建一个HTTP服务器，通过API接口提供视频数据。使用HttpClient从Python服务器获取视频帧，并将其显示在PictureBox中。ZeroMQ是一种高性能的异步消息库，适用于需要低延迟和高吞吐量的应用。

机器学习和深度学习在定义、基本原理、数据需求、模型结构、计算需求、可解释性和应用领域等方面存在一些差别。机器学习是一个更广泛的概念，包括了许多不同的算法和技术，而深度学习是机器学习的一个子领域，专注于使用深度神经网络来学习数据中的复杂模式和表示。在实际应用中，需要根据具体的问题和数据特点选择合适的方法。

图像融合是将拼接后的图像进行平滑过渡，以消除拼接痕迹的过程。为了解决大尺寸图像拼接的问题，可以采用分块拼接的方法，将大尺寸图像分成若干小块进行拼接，然后再将小块拼接成完整的图像。然而，由于图像的光照、视角、尺度等变化，以及噪声、模糊等因素的影响，特征点的检测和匹配往往存在一定的难度。2024年了，谈论图像拼接，不算新事物，我们这里探讨图像拼接，主要探讨图像拼接的意义、难点和大概的实现思路。图像拼接，可以先做特征点检测、然后特征点匹配，最后做图像的融合，以下我们就每个阶段，基于OpenCV，做个大概的探讨。

好多开发者希望找个更适合自己的RTSP播放器，下面四款RTSP播放器功能和使用场景比较，可以作为参考

RTSP在低延迟的直播场景下，意义重大，特别是好多监控摄像头，默认就是提供的RTSP流，如果播放器延迟足够低，技术方案非常简单，灵活性和可扩展性非常高。

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

ONVIF（Open Network Video Interface Forum）即开放型网络视频接口论坛，是一个全球性的开放性行业论坛，旨在推动基于网络的物理安防产品的互操作性。好多开发者希望搞明白ONVIF和GB28181的区别和各自适合的场景，为什么大牛直播SDK只做了GB28181接入端，没有做ONVIF？本文就二者差别，做个大概的介绍。GB28181 即《公共安全视频监控联网系统信息传输、交换、控制技术要求》，是中国国家标准，在视频监控领域发挥着重要作用。

好多开发者使用场景，除了实现基础的低延迟RTSP、RTMP播放外，还需要实现RTSP、RTMP流数据的本地录像功能。本文以大牛直播SDK的Windows平台播放模块为例，介绍下如何实现RTSP、RTMP流录像。

大牛直播SDK推出的Android平台GB28181接入SDK（SmartGBD），可实现不具备国标音视频能力的 Android终端，通过平台注册接入到现有的GB/T28181—2016服务，可用于如执法记录仪、智能安全帽、智能监控、智慧零售、智慧教育、远程办公、明厨亮灶、智慧交通、智慧工地、雪亮工程、平安乡村、生产运输、车载终端等场景。

在Android 平台上支持GB28181时，设备注册失败可能是由于设备信息配置问题、网络连接问题、服务器配置问题、协议兼容性问题或其他问题导致的。通过仔细检查和排除这些可能的原因，可以提高设备注册的成功率。

在无人驾驶的远程操控场景中，车辆行驶状态的变化需要迅速反馈给远程操作员，操作员的指令也需要尽快传达到车辆，延迟应尽可能控制在几百毫秒以内，以确保车辆能够及时响应操控指令，保持稳定行驶。例如在体育竞技中的平衡项目，如体操、花样滑冰等，可以通过多个摄像头从不同角度拍摄运动员的动作，为教练和裁判提供更全面的视角，以便准确评估运动员的平衡表现。在工业自动化领域，对大型设备的远程监控和操作需要稳定的音视频直播，以确保操作人员能够持续、准确地了解设备的运行状态，进行有效的平衡操控。

以GB28181设备接入模块为例，摄像头实时视频采集，可以叠加上实时CPU占用和实时电量信息，亦或实时时间信息，会对场景带来很大益处，比如CPU占用率或电量信息，简单来说可以通过bitmap把文字读取下来，投递到底层比如jni层即可，非常方便。png水印，除了常规的位置需要注意之外，还涉及到logo水印的大小问题，为此，我们添加了缩放效果，可以缩放后，再贴到图层，确保以更合适的比例展示在图层期望位置。需要注意的是，获取电池电量信息可能需要相应的权限。

GB28181 的应用范围将不仅仅局限于安防领域，还会向其他行业拓展。例如，在教育、医疗、金融等行业，视频监控系统也有着广泛的需求。GB28181 可以为这些行业的视频监控系统提供标准化的解决方案，促进不同行业之间的视频资源整合和共享。

做RTMP、RTSP播放器容易，做个好的播放器，真的要投入几十倍的精力，大牛直播SDK始于2015年，通过自有框架、自适应算法、RTSP 播放器协议自动切换、缓冲时间设置以及底层原生模块等多方面的优化，共同保证了超低延迟的播放体验。在实际应用中，这些技术手段相互配合，根据不同的网络环境和硬件条件进行自动调整，为用户提供了高质量、低延迟的直播服务。

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

Android平台GB28181接入SDK（SmartGBD），可实现不具备国标音视频能力的 Android终端，通过平台注册接入到现有的GB/T28181—2016服务，可用于如执法记录仪、智能安全帽、智能监控、智慧零售、智慧教育、远程办公、明厨亮灶、智慧交通、智慧工地、雪亮工程、平安乡村、生产运输、车载终端等场景。

RTMP 播放器是一种专门用于播放采用 RTMP（Real Time Messaging Protocol）协议的视频流的工具。在当今的流媒体播放领域中，它扮演着至关重要的角色。RTMP 播放器能够实时接收、解码和播放来自服务器的音频、视频数据，为用户提供流畅的观看体验。在直播场景中，RTMP 播放器能够实现低延迟播放，让观众与主持人之间的互动更加及时。例如，在会议类直播中，参会者可以通过文字聊天与主讲人互动，而 RTMP 播放器的低延迟特性能够确保观众的评论和主讲人的回应之间的时间差尽可能小。

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

RTMP优势在于它能够提供低延迟的实时音视频传输，同时具有良好的跨平台支持，可以在不同的操作系统和设备上运行。2005年，我们做Android平台RTMP推送模块的初衷，是为了满足传统行业如应急指挥、巡检等场景的低延迟视音频传输，达到远程指挥的目的。做好了RTMP推送模块，发现现有的RTMP播放都不足以满足我们毫秒级的延迟诉求，继续自研框架，做了RTMP的直播播放器。

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

RTMP、RTSP、RTP、HLS、DASH这些协议在流媒体传输领域各有特点，但也有一些共同点。分别在实时视频传输中各有优势，选择哪种协议取决于具体的应用场景、网络条件以及设备兼容性等因素。

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

大多数RTSP的播放都面向直播场景，所以，如果延迟过大，严重影响体验，所以，低延迟是衡量一个好的RTSP播放器非常重要的指标，目前大牛直播SDK的RTSP直播播放延迟比开源播放器更优异，而且长时间运行下，不会造成延迟累积；好多开发者希望了解下RTSP播放器相关的技术实现，却又有很多人，止步于RTSP的繁琐复杂，本文我们先从RTSP规范层面，对协议栈有个粗浅的解读，然后配合RTSP播放器功能和接口设计，普及下RTSP播放器的实现逻辑。