背景在比较同一个数据源,是RTMP播放延迟低还是RTSP延迟低之前,我们先看看RTMP和RTSP的区别,我们知道,RTMP(Real-Time Messaging Protocol)和RTSP(Real RTMP以二进制形式传输数据,具有低延迟和高效传输的特点。RTSP:RTSP则是一种控制流媒体会话的协议,它不直接传输媒体数据本身,而是负责描述流媒体会话,并指示客户端如何获取流媒体数据。 应用范围RTMP:RTMP因其低延迟和高效传输的特点,广泛应用于需要高性能实时流媒体传输的场景,如直播、视频聊天等。 ,用我们的RTMP推送、轻量级RTSP服务、RTMP|RTSP播放器,延迟基本上相差无几,可见,配好的推拉流服务模块,尤其关键。 单就延迟来看,如果好的RTMP或RTSP播放,二者差异不大,主要是看实际场景。以上是大概的比较,感兴趣的开发者,可以单独跟我沟通探讨。
技术背景 实际上,我们在2015年做Android平台RTSP、RTMP播放模块的时候,第一版就支持了多实例播放,因为SDK设计比较灵活,做个简单的player实例封装即可实现多实例播放(Android 1 : 0); //设置RTSP超时时间 int rtsp_timeout = 10; lib_player_.SmartPlayerSetRTSPTimeout(handle, rtsp_timeout ); //设置RTSP TCP/UDP模式自动切换 int is_auto_switch_tcp_udp = 1; lib_player_.SmartPlayerSetRTSPAutoSwitchTcpUdp is_auto_switch_tcp_udp); lib_player_.SmartPlayerSaveImageFlag(handle, 1); // It only used when playback RTSP 毫秒级延迟,完全满足对延迟、稳定性要求苛刻的场景下。感兴趣的开发者,可以单独和我沟通。
好多开发者在QT环境下实现RTMP或RTSP播放时,首先考虑到的是集成VLC,集成后,却发现VLC在延迟、断网重连、稳定性等各个方面不尽人意,无法满足上线环境需求。 本文以调用大牛直播SDK(官方)的Windows平台播放端SDK为例,介绍下如何在QT下实现低延迟的RTMP|RTSP播放器,废话不多说,先上图: QTPlayer.png 大牛直播SDK有MFC的demo OpenPlayerHandle(url, is_rtsp_tcp_mode, is_mute)) return false; player_api_->SetBuffer(player_handle play->OnWindowSize(widgets.at(i)->width(), widgets.at(i)->height()); } } } 以上是QT环境下集成个低延迟的 RTMP、RTSP播放的基本流程,感兴趣的开发者可酌情参考。
在AI与机器人技术交汇的浪潮中,低延迟视频链路已成为人形机器人突破“感知-决策-执行”闭环的关键瓶颈。 如同人类的视觉系统是行动的先导,高质量、低延迟的视频传输链路已成为人形机器人的“数字视觉神经”——它承载着机器人“看清”世界的关键信息流。 以下三大挑战,构成了人形机器人实现可靠、实时交互必须逾越的技术鸿沟:1. 延迟:悬于毫秒之间的“生死线”人形机器人的行动价值,核心在于“实时”。 传统基于公网或通用流媒体协议(如标准RTMP/RTSP)的方案,动辄数百毫秒甚至数秒的端到端延迟,在机器人高速动态场景下,无异于“蒙眼狂奔”。 数据印证未来: 2025年全球机器人视频流处理量将达15EB/天(年均增长230%) 低延迟视频技术使人形机器人任务成功率提升55% 每毫秒延迟降低带来$27的边际经济效益(制造业场景) 在这场人机共生的进化中
因此,在电机、材料、场景之外,还存在一个往往被低估但至关重要的 隐性战场 —— 低延迟、跨平台、可控的视频与感知链路。这是机器人从“会动”走向“好用”、从“原型机”走向“规模化应用”的关键门槛。 它像“神经网络”一样,为人形机器人提供跨平台、低延迟的视频通道,让感知—决策—执行的闭环真正跑得起来。这条隐形赛道,也许才是决定未来胜负的“关键一役”。 这正是大牛直播SDK发挥作用的地方: 低延迟视频链路:RTSP/RTMP 播放器延迟控制在 100–200ms,确保“看到”与“做到”之间几乎无差。 工业制造:跨产线物流、柔性制造要求机器人在嘈杂、复杂网络环境下依然保持稳定低延迟。SDK 的转发与录像模块,保证任务可溯源,数据可回放。 六、结语:得关节者得天下,得链路者赢未来未来十年,人形机器人行业的竞争逻辑,不仅仅是电机、材料、场景的显性战场,更包括低延迟、跨平台、可控的视频链路这一隐性赛道。
提供RTSP TCP/UDP模式设置及自动切换功能,适应不同网络环境,确保播放稳定性。 1.1.2 性能优化特性 内置低延迟模式,可将延迟控制在毫秒级别,满足实时性要求高的场景。 低延迟播放技术实现3.1 网络优化策略3.1.1 缓冲时间设置 将缓冲时间设置在几十毫秒到几百毫秒之间,减少数据缓冲带来的延迟,同时保证播放稳定性。 4.2 低延迟关键参数配置4.2.1 网络协议优化 RTSP模式选择:默认使用UDP(NT_SP_SetRTSPTcpMode设为0)以减少握手延迟,若网络不稳定则开启TCP/UDP自动切换(NT_SP_SetRtspAutoSwitchTcpUdp 快速启动与低延迟模式: NT_SP_SetFastStartup(handle, 1); // 跳过CDN缓存GOP NT_SP_SetLowLatencyMode(handle, 1); // RTSP/RTMP播放器,适用于VR、安防、直播等高实时性场景。
实现RTSP摄像头数据转RTMP推送到服务器,可以用第三方库或者工具实现,总体设计架构如下:图片一个好的转发模块,首先要低延迟! 其次足够稳定、灵活、有状态反馈机制、资源占用低,跨平台,最好以接口形式提供,便于第三方系统集成,整体功能设计如下:1. 拉流:通过RTSP直播播放SDK的数据回调接口,拿到音视频数据;2. 您可以使用以下命令行参数:ffmpeg -i rtsp://[摄像头地址]/[流媒体地址] -f flv rtmp://[服务器地址]/[直播频道]其中,rtsp://[摄像头地址]/[流媒体地址] 拉流:拉流和播放有些类似,但不需要播放(也就是说不要解码,资源消耗非常低),在做过基础的参数配置之后(对应demo里面OpenPullHandle()),设置音视频数据回调,然后调用StartPullStream 需要确保系统具有足够的处理能力和带宽,以避免延迟或丢帧等问题。
当然,话说回来,如果是在特定的使用场景下,只需要某些版本IE浏览器支持,但对延迟和稳定性要求非常高,OCX控件方式也不失为一个好的选择。 hls流(如果可以忍受几秒甚至十几秒延迟的话)。 本文基于大牛直播SDK https://github.com/daniulive/SmarterStreaming 现有RTSP、RTMP播放接口的基础上,二次封装,扩展了ocx控件,用于IE浏览器下的低延迟 ULONG NT_SetLowLatencyMode(LONG mode); 设置是否低延迟模式播放; 13. OpenPlayer(); } var obj = document.getElementById("SmartPlayerActiveX"); //设置是否启用低延迟模式
一、风口之下的挑战:人形机器人为什么需要低延迟?近几个月,人形机器人赛道迎来资本与技术的双重关注。从产业巨头宣布量产计划,到专业赛事和行业大会的火热进行,市场对这一领域的预期正在不断攀升。 亚秒级传输延迟传统的RTMP、RTSP协议在普通应用中延迟往往达到1–3秒,这对于人形机器人控制、远程医疗等场景来说不可接受。 协议优化 + 硬件加速双重强化在低延迟的实现上,SDK通过减少RTMP/RTSP协议冗余、优化缓存策略,最大化缩短数据传输路径。 大牛直播SDK的技术支撑点 低延迟优化:通过自研 RTMP/RTSP 核心协议栈,支持毫秒级延迟,适用于工业远程控制、巡检等场景。 大牛直播SDK的角色在这一产业变革中,大牛直播SDK作为低延迟音视频传输的重要工具,提供了多协议支持(RTMP、RTSP、SRT)、跨平台兼容和自适应网络优化,这使其成为机器人厂商在构建实时交互系统时的优选方案
在Unity3D平台上实现全景实时RTMP或RTSP流渲染,可以通过以下方式:获取全景视频数据源:首先,需要拉取RTMP或RTSP流数据,解码后,把RGB或YUV数据,回调到unity,从而获取到全景视频流数据 技术实现图片本文以大牛直播SDK的RTMP推送端作为数据采集,获取全景窗体数据后,编码打包推送到RTMP服务,或启动个轻量级RTSP服务,对外提供个RTSP的拉流URL。 然后,播放端,拉取RTSP或RTMP的URL,把YUV或RGB数据回调上来,然后,再在Unity窗体绘制出来。 1 : 0); //设置是否启用低延迟模式 //设置旋转角度(设置0, 90, 180, 270度有效,其他值无效) int rotate_degrees = 0; 与此同时,Unity全景实时播放,需要有非常高的延迟要求和性能要求,特别是全景数据源,分辨率和码率都非常高,对解码效率和解码后的数据拷贝投递,提了更高的要求。
传统的单路播放器已无法满足此类需求,因此开发一个多路 RTSP 播放器显得尤为必要。该播放器主要面向以下场景: 视频监控中心 :对多个监控摄像头进行实时监控,要求低延迟、高稳定性。 is_hardware_decoder && is_enable_hardware_render_mode) { lib_player_.SmartPlayerSetHWRenderMode(get(), 1);}(二)低延迟模式为了满足实时性要求较高的场景 ,可以启用低延迟模式。 在 configurePlayer 方法中设置低延迟模式。 性能优化 :采用硬件加速、低延迟模式等技术手段,提高播放性能和实时性。 良好的资源管理 :合理管理播放器的生命周期和资源,避免内存泄漏和资源浪费。
从大牛直播SDK的视角看,行业的喧嚣背后真正的挑战在于:机器人是否具备足够稳定、低延迟、跨平台的感知与交互通道。这些音视频链路才是决定人形机器人能否从实验室走向规模化应用的关键基石。 RTSP 服务:在本地环境中即可搭建低延迟内网传输,避免依赖复杂的云端部署; 播放模块:跨平台低延迟播放器,确保远程端与指挥端能够无缝接收反馈; 转发与录像模块:支持多路分发与本地存证,让机器人不止是 结合大牛直播SDK的能力,可以看到几个典型落地方向: 制造业与工业巡检 人形机器人替代工人完成危险或重复性任务; SDK 的低延迟链路保障后台可实时监控,远程操控可快速响应突发。 这些场景说明:真正的需求并不等于订单数字,而是能否在复杂网络与多样化平台下依旧保持稳定和低延迟。这也是资本逻辑无法替代的“技术硬实力”。 只有当机器人真正具备稳定、低延迟、跨平台的感知与交互能力,行业才可能穿越喧嚣,抵达规模化落地的彼岸。进化没有捷径,唯有清醒和笃定,才能行稳致远。
凭借其开源、高效、易于集成等优势,这一组合被广泛应用于安防监控、工业质检、无人机巡检、智慧交通、医疗影像、机器人导航等多个关键场景,正在推动着传统行业向“智能化、自动化、实时化”转型。 传统方式如使用摄像头采集、调用 ffmpeg 解码、使用 OpenCV 的 cv2.VideoCapture(),往往面临: ❌ 帧率不稳、延迟高; ❌ 不支持 RTSP/RTMP 等协议或兼容性差; 技术链路RTSP摄像头 → 大牛直播SDK拉流 → YOLOv5识别人形目标 → 置信度>0.8 → 调用报警接口(如 MQTT / HTTP) 技术亮点 视频延迟 < 200ms; 实时叠加识别框 案例三:远程巡检 + 图像标注上传(无人机/机器人)✅ 场景描述在电力巡线、园区安防、石油管道等场景中,部署无人机或机器人,搭载 RTMP 图传系统将现场图像实时推流,后台系统接收后进行 AI 分析与人工辅助标注 /本地流,低延迟、高稳定帧级回调层RGB/YUV 输出精准对接 Python/AI 模型,毫秒级响应图像分析层OpenCV + YOLO/Haar支持人脸识别、目标检测、行为分析等数据联动层HTTP/MQTT
在发布国产操作系统|Linux平台的RTMP|RTSP直播播放SDK之前,大牛直播SDK在Windows、Android、iOS平台已经有了非常成熟的技术积累,功能齐全、稳定性高、超低延迟、超低资源占用 、网络自动重连等,RTMP支持扩展H265播放, RTSP也支持H265播放。 Linux原生的RTSP、RTMP播放模块这里我们不做赘述,本文主要讲的是如何在Linux平台构建Unity下的RTSP和RTMP低延迟直播播放。 播放模块,拉流解码延迟非常低,数据投递效率非常高,无图无真相:Linux平台,我们是回调的YUV的数据,也就是 NT_SP_E_VIDEO_FRAME_FROMAT_I420: /*定义视频帧图像格式 1 : 0); //设置是否启用低延迟模式//设置旋转角度(设置0, 90, 180, 270度有效,其他值无效)int rotate_degrees = 0;NTSmartPlayerSDK.NT_SP_SetRotation
本文是来自WWDC(苹果全球开发者大会) 2019的演讲,演讲的作者Roger Pantos,HLS的技术主管,本次演讲主题是介绍低延迟HTTP实时流(Low-Latency HLS)的实现和效果以及如何使用低延迟 在演讲的开始,Roger首先描述了低延迟对于体育直播、新闻、即时互动游戏广播以及颁奖典礼和其他社交媒体活动等的重要性。 介绍了低延迟HLS的设计目标是1-2秒,并且具有速率适配、加密、广告、元数据、向后兼容等功能。 然后Roger介绍了低延迟HLS如何实现上述的目标,与之前的HLS相比有5大变化:减少发布延时、优化段发现、消除段往返、减少播放列表传输开销、快速切换层。随后介绍了完成这5项变化的细节。 接着Roger展示了使用低延迟HLS视频通话的延迟,在AppleTV上美国用户与澳大利亚用户在视频通话时的延迟低于2秒。 最后Roger介绍了对于开发者来说,如何使用低延迟HLS进行项目开发。
AI 大模型与算力基础设施持续突破,人形机器人与低空经济迈入量产阶段,智能驾驶和固态电池加快商业化,量子计算与前沿技术逐渐实现工程化,消费电子也迎来新一轮交互升级。 人形机器人与具身智能:低延迟感知与远程操控的核心如果说大模型和算力让 AI 有了“大脑”,那么人形机器人就是它的“身体”。 在人形机器人赛道,视频链路的质量已经成为机器人落地的隐形门槛,而大牛直播SDK正是帮助厂商跨越这一门槛的关键技术之一。3. 低延迟链路保障:在 5G/专网环境下,端到端延迟可控制在 200ms 级别,支持远程实时指挥。 :实时感知、低延迟交互、跨平台可控。
技术探讨自2017年我们发布跨平台的低延迟Unity下的RTSP|RTMP直播播放器后,Unity下的直播体验有了质的提升,特别是RTMP,从大家认知里面的几秒钟,直接缩减到100-300ms,满足了绝大多数场景下低延迟的技术诉求 今天就Unity下的RTSP|RTMP的低延迟播放,从以下几个维度,抛砖引玉,做个探讨: 选择合适的播放插件 Unity下的RTSP|RTMP低延迟播放,业内想到最多的是大牛直播SDK的SmartPlayer 低延迟模式:如果插件或 SDK 提供了低延迟模式的选项,一定要开启该模式。不过,有些情况下开启低延迟模式可能会牺牲一定的视频质量或稳定性,需要进行权衡。 tcp-udp模式设置、rtsp超时时间设置、低延迟模式设置等)。 流,资源占用如下:总结Windows平台如果对延迟和资源占有等,要求非常高,可以选择合适的低延迟RTSP或RTMP播放插件、优化播放参数设置、优化网络环境、优化代码和渲染流程。
背景我们看过了太多介绍RTSP、RTMP播放相关的技术资料,大多接口设计简约,延迟和扩展能力也受到一定的局限,好多开发者希望我们能从接口设计的角度,大概介绍下大牛直播SDK关于RTMP、RTSP播放器开发设计 低延迟模式低延迟模式下,设置buffer time为0,延迟更低,适用于比如需要操控控制的超低延迟场景下。 /*设置低延时播放模式,默认是正常播放模式mode: 1为低延时模式, 0为正常模式,其他只无效接口调用成功返回NT_ERC_OK*/NT_UINT32(NT_API* SetLowLatencyMode ,这里就不再赘述,除Windows平台外,我们还同步开发了Linux、Android、iOS平台的RTSP、RTMP播放器,大多常规接口四个平台基本统一,延迟也都做到了毫秒级。 一个好的播放器,特别是要满足低延迟稳定的播放(毫秒级延迟),需要注意的点远不止如此,感兴趣的开发者,可以参考blog其他文章。
当外界把注意力集中在会走路、会做表情、皮肤逼真的“人形”外观时,真正决定机器人价值上限的,是它能否稳定感知、理性决策、可靠执行。 在机器人领域,答案也并不神秘:功能优先才是硬道理。要让机器人在工厂、医院、园区、矿区与城市街区“干活”,必须有一条低延迟、跨平台、可组装的感知—推理—执行链路。 这正是 大牛直播SDK(SmartMediaKit) 的定位:提供面向机器人与边缘智能的低延迟 RTSP 播放/服务、内网公网 RTMP 分发(含 Enhanced RTMP + HEVC/H.265) 视频链路的战略地位(SDK = 神经系统)大牛直播SDK 作为“神经系统”的角色在于: 专网低延迟(RTSP 播放/服务)满足近距离操控、现场监看、边缘推理,整体延迟100-200ms; 公网分发(RTMP 落地案例拼图(示例)案例 A|工业巡检车(专网) 链路:多目相机/热成像 → RTSP 推流 → 端侧轻量 RTSP 服务 → 中台 RTSP 低延迟播放 → AI 缺陷检测 → 任务派发/路径调整
技术实现如何在VR头显实现RTMP或RTSP播放? VR头显播放RTMP或RTSP流数据,简单来说,通过jni层打通RTMP或RTSP流传输,解包并解码回调给Unity YUV或RGB数据,Unity场景下,绘制即可,本文以大牛直播SDK的Unity平台 1 : 0); //设置是否启用低延迟模式 NT_U3D_SetMute(player_handle_, is_mute_ ? player_obj_.Call<int>("SetFastStartup", handle, is_fast_startup); } ///