乐学吧

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

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

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

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

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

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

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

好多开发者在播放RTSP或RTMP流的时候，特别是多路播放的时候，希望能试试调节单个视频画面的声音（静音或放大缩小音量）

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

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

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

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

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

直接在Unity中播放RTMP|RTSP流可能并不简单，因为Unity没有内置对RTMP|RTSP的直接支持。你需要根据你的具体需求（如是否需要实时交互、流的来源、你的技术栈等）来选择最合适的解决方案。对于大多数应用场景，使用插件或服务器端转码可能是最简单有效的方法，但不是效率最高的办法，特别是对延迟要求比较高的场景，可以考虑使用大牛直播SDK这种专业的Unity RTMP|RTSP播放模块，无论是延迟还是稳定性，均可达到业内顶级的水准。

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

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

iOS平台RTSP、RTMP直播播放模块，延迟低、资源占有少，性能优异。由于设备和系统比较单一，优先考虑硬解码，除了基础播放外，我们还实现了实时快照、实时录像、实时回调YUV数据、实时音量调节等，实际体验下来，iOS平台RTMP和RTSP，可以轻松毫秒级。

好多开发者对无人机巡检技术方案，相对陌生，实际上，无人机巡检就是利用无人机对特定区域或设施进行定期或不定期的检查。这种巡检方式相比传统的人工巡检具有显著的优势，包括速度快、覆盖广、风险低、准确性高等。无人机巡检的优势：无人机能够迅速覆盖大面积区域，特别是在地形复杂或难以到达的地方，如山区、河流等，大大提高了巡检效率。据相关数据表明，无人机巡线比人工巡线效率高出40倍。

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

RTP是一种网络协议，用于在互联网上传输具有实时属性的数据，如音频、视频等。功能：提供端到端的网络传输功能，支持多播（Multicast）或单播（Unicast）网络服务。特点：RTP本身不提供任何机制来确保及时交付或提供其他服务质量保证（QoS），而是依赖于较低层的服务来完成这些工作。它不保证传输或防止乱序传输，也不假设底层网络是可靠的并按顺序传输数据包。定义：RTCP是RTP的配套协议，用于监控服务质量并传递正在进行的会话中参与者的信息。

通过优化编码、推流和拉流过程，实现低延迟、高清晰度的音视频传输，为医生和学生提供优质的手术观摩和学习环境，以上是大概方案探究，感兴趣的网友，可以跟我单独探讨。：通过优化编码、推流和拉流过程，尽量降低音视频传输的延迟，确保医生和学生能够实时观看手术过程，整体延迟，尽量控制在150-300ms左右，达到互动延迟水准。手术示教场景，可通过RTMP推送（采集屏幕或摄像头）、RTMP|RTSP播放，RTSP转RTMP推送多模块组合，可实现低延迟的示教体验。播放端需支持多种设备和平台，以便满足不同用户的需求。

搜索引擎搜大牛直播SDK，居然提示我搜“大牛直播SDK最经典的一句”，闲来无事，点开看看，AI智能问答，给出了答案：‌‌ 这句话体现了大牛直播SDK专注于自己擅长的领域，同时提供开放接口，使得开发者可以方便地将其他功能集成到SDK中，从而满足更广泛的应用需求。这种专注于核心功能同时保持开放性的策略，使得大牛直播SDK能够在激烈的市场竞争中脱颖而出，成为业界的佼佼者‌。突然对AI智能问答，有了好感。

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

大牛直播RTSP/RTMP播放器SDK特点：在没测试过大牛直播SDK的RTMP和RTSP播放器之前，你甚至不相信行业内，RTMP和RTSP播放器（特别是RTMP播放器）延迟可以稳定的做到1秒以内。无需赘述，全自研内核，行业内一致认可的跨平台RTSP/RTMP直播播放器SDK，功能齐全、高稳定、超低延迟、近200家公司明智之选。功能支持：如不单独说明，系Windows、Android...

随着H.265的普及，越来越多的开发者希望大牛直播SDK能支持低延迟的RTSP H.265播放，并分享相关经验：实现思路：对rtsp来说，要播放h265只要正确解析sdp和rtp包即可. 下面对这些相关内容做一些介绍.1. H265 Nal Unit Header 简单介绍:H264的Nal Unit头是一个字节，265变成两个字节:F: 1 bit. forbidden_z...

二话不说，NO 图 NO BB（以大牛直播SDK播放海康摄像机RTSP H.265流为例）：行业的浮躁，好多开发者甚至连rtsp、rtp细节不了解，依葫芦画瓢调用了ffmpeg的一些接口，就实现了个简单版的播放器，导致不少开发者找我们交流的时候甚至说，实现个RTSP播放很容易，两三周或个把月就可以做到你们这个程度，一般我们不置可否，被问的多了，偶尔也反驳一句：我们原地踏步1年你也不一定能赶...

很多开发者在开发RTSP或RTMP播放器的时候，不晓得哪些event回调事件是有意义的，针对此，我们以大牛直播SDK（github）的Android平台RTSP/RTMP直播播放端为例，简单介绍下常用的event id，总的来说，有以下几个部分组成：1. 常规网络状态显示：如开始播放、网络中断、重连、收不到媒体数据等；2. 视频宽高信息回调：用于上层显示回调的分辨率信息；3. 快速切换url：如播放过程中，切换其他url时，分辨率发生变化，给到回调事件；4. 录像状态：如开始录像、录像完成；

介绍移动端RTMP、RTSP播放器实时音量调节之前，我们之前也写过，为什么windows播放端加这样的接口，windows端播放器在多窗口大屏显示的场景下尤其需要，尽管我们老早就有了实时静音接口，相对实时静音来说，播放端实时音量调节粒度更细，从[0, 100]，用户体验更好。为什么要做实时音量调节RTMP或RTSP直播播放音量调节，主要用于多实例（多窗口）播放场景下，比如同时播放4路RTMP或RTSP流，如果音频全部打开，几路audio同时打开，可能会影响用户体验，我们通用的做法是支持播放端实时静音

本文主要抛砖引玉，粗略介绍下Android平台RTMP/RTSP播放器中解码和绘制相关的部分(Github)。解码提到解码，大家都知道软硬解，甚至一些公司觉得硬解码已经足够通用，慢慢抛弃软解了，如果考虑到设备匹配，软硬解码都支持，是个不错的选择，为此，大牛直播SDK在开发这块的时候，分类是这样的：1. 软解码：解码后获取到原始数据，可进行后续的原始数据回调和快照等操作；2. 硬解码：解码后获取到原始数据，可进行后续的原始数据回调和快照等操作；3. 硬解码：设置surface模式，直接re

好多开发者在做产品竞品分析的时候，不知道如何界定一个RTSP播放器，大牛直播SDK认为，一个RTSP播放器，不是说有几个类似于Open/Close接口就够了，好的RTSP播放器需要具备以下功能和性能属性：1. 低延迟：大多数RTSP的播放都面向直播场景，所以，如果延迟过大，比如监控行业，小偷都走了，客户端才看到，或者别人已经按过门铃几秒，主人才看到图像，严重影响体验，所以，低延迟是衡量一个好的...

好多开发者，在自研或者选择市面上的播放器的时候，除了常规的播放功能，还有很多点值得关注，如延迟、资源占用、网络异常处理、多实例支持、长时间运行稳定性等。以下是我们开发直播播放器过程中，考虑的部分关键因素（以Windows平台RTSP直播播放为例，如需下载demo源码，可以到 Github 下载）：1. 低延迟：大多数RTSP的播放都面向直播场景，所以，如果延迟过大，严重影响体验，所以，低延迟是...

为什么要做实时音量调节RTMP或RTSP直播播放音量调节，主要用于多实例（多窗口）播放场景下，比如同时播放4路RTMP或RTSP流，如果音频全部打开，几路audio同时打开，可能会影响用户体验，我们通用的做法是支持播放端实时静音，更细粒度的做法是可以实时调节每一路RTMP/RTSP流的音量。音量调节接口设计RTMP或RTSP直播播放端音量调节功能设计主要考虑到一点，和市面通用的本地播放器或点播播放器功能对齐（如VLC、PotPlayer等），音量可以实时调整即可，本文以大牛直播SDK的Windo

好多开发者认为，无论是RTSP/RTMP推送端还是RTSP/RTMP播放端，涉及到录像，只要2个接口足矣：开始录像、停止录像。实际场景下，一个好的录像模块，2个接口远远不够， 本文以大牛直播SDK（Github）RTSP/RTMP推送和RTSP/RTMP播放端扩展录像模块为例，介绍下一个好的录像模块，需要具备哪些基本功能属性。Android、iOS平台不再赘述，本文以Windows平台C#接口为例，先说推送端：1. 设置录像目录录像目录不必多解释，为了便于录像文件管理，设置指定的录像目录是基

我们在实现Windows平台RTSP播放器或RTMP播放器的时候，需要考虑的点很多，比如多实例设计、多绘制模式兼容、软硬解码支持、快照、RTSP下TCP-UDP自动切换等，以下就其中几个方面，做个大概的探讨。1. 视频绘制模式我们在实现Windows平台播放的时候，一般首选D3D，D3D不支持的情况下，考虑数据回上来，采用GDI模式，一般实现如下，先做D3D检测，以大牛直播SDK播放端为例（Github），调用NT_SP_IsSupportD3DRender()，检测是否支持D3D模式，如果支持的话

好多开发者在做Windows平台特别是单屏多画面显示时，希望像监控摄像机一样，可以在播放画面添加OSD台标，以实现字符叠加效果，大多开发者可很轻松的实现以上效果，针对此，本文以大牛直播SDK （Github）的Windows平台demo为例，简单介绍下具体实现：Windows平台RTMP播放器、RTSP播放器C++ demoWindows平台C++的demo，以录像过程为例，动态在左上角显示个闪动的图标+当前时间，具体效果如下：核心代码std::shared_ptr<nt_arg

我们在Windows平台实现RTSP或者RTMP播放的时候，有个功能是绕不开的，那就是播放窗口全屏。本文就以大牛直播SDK（官方）的Windows播放器为例，大概讲下大概实现：全屏播放需要考虑的点不多：第一：视频播放后，全屏的意义；第二：全屏后，是否等比例显示，我们的设计原则是，之前等比例显示的，继续等比例显示，之前铺满的，继续铺满；第三：ESC退出全屏。本文以C++的demo为例，具体实现如下：void nt_wrapper_render_wnd::FullScreenSwitc

不管是基于开源播放器二次开发，还是全自研内核，一个好的RTMP播放器或RTSP播放器，设计的时候，更多考虑的应该是如何做的更灵活、更稳定、延迟更低、资源占用更小，单纯的几个接口，很难满足通用化的产品诉求，啰啰嗦嗦说了这么多，权当抛砖引玉，感兴趣的开发者，可以酌情参考。

技术背景无论是Windows平台还是Linux，多路播放诉求非常普遍，比如针对智慧工地、展馆、教育等宏观场景下的摄像头展示，关于RTSP或RTMP直播播放器开发需要注意的点，可参考之前博客，总的来说有以下一些点：1. 低延迟：大多数RTSP的播放都面向直播场景，所以，如果延迟过大，比如监控行业，小偷都走了，客户端才看到，或者别人已经按过门铃几秒，主人才看到图像，严重影响体验，所以，低延迟是衡量一个好的RTSP播放器非常重要的指标，目前大牛直播SDK的RTSP播放延迟控制在几百毫秒，VLC在几秒，这个

好多开发者提到，在目前开源播放器如此泛滥的情况下，为什么还需要做自研框架的RTSP播放器，自研和开源播放器，到底好在哪些方面？以下大概聊聊我们的一点经验，感兴趣的，可以关注github：1.低延迟：大多数RTSP的播放都面向直播场景，如果延迟过大，严重影响体验，所以，低延迟是衡量一个好的RTSP播放器非常重要的指标，目前大牛直播SDK的RTSP直播播放延迟比开源播放器更优异（大牛直播SDK延迟在1秒左右，开源播放器如VLC，延迟相对比较大），而且长时间运行下，大牛直播SDK播放端不会造成延迟累积，开..

先说回调yuv或rgb这块意义吧，不管是RTSP还是RTMP直播播放模块，解码后的yuv/rgb数据，可以实现比如快照（编码保存png或jpeg）、回调给第三方用于比如视频分析、亦或比如回调给Unity，实现Unity平台下的绘制。正好前些年我们做RTSP和RTMP直播播放的时候，实现过相关的需求，本文就以Android为例，大概说说具体实现吧。今天某乎收到个问题推荐，如何实现RTSP回调YUV数据，用于二次处理？为了验证回上来的数据是否正常，我们加了保存jpeg文件的代码。