然而,在过去几年中,低延迟在实施和标准化方面取得了很多进展,因此我们的处境要比几年前好得多。低延迟的主要驱动因素之一就是现场体育赛事。 几秒钟后,视频继续播放,这会很烦人,尤其是和朋友一起看比赛的时候。 自适应播放技术概述 低延迟体育节目是低延迟直播的主要驱动力。 在提供优质的低延迟实时流媒体服务这方面,我们开发了一些实用的技术,比如说自适应播放——通过改变每秒播放的帧数来减慢播放速度,并对音频和字幕做同样的事情。 请注意,虽然 CAPSC 可以在短期内改变播放速度,但在低延迟直播中,长期平均播放速度不能快于 1 倍。 如果是这样,CAPSC 会选择较慢的播放速度。如果当前缓冲区级别不是非常低,CAPSC 检查当前延迟和目标延迟之间的差异,并选择 1x 或更高的值作为播放速度。
Electron 低延迟视频流播放方案探索 Bobi.ink 2020-04-05 好久不见,接近四个月没更新博客了! 唯一的要求是低延迟,低资源消耗: 我们视频会议语音和视频是分离的。 只有一路混合语音,通过 SIP 传输。而会议视频则可能存在多路,使用 WebRTC 进行传输。 目录 ① 典型的Web直播方案 RTMP 推流 RTMP 拉流 RTMP 低延迟优化 ② JSMpeg & BroadwayJS Relay 服务器 推送 视频播放 多进程优化 简单说一下 Broadway.js 延时低,实时性较好。不过浏览器需要借助 Flash 才能播放; 但是我们也可以转换成 HTTP/Websocket 流喂给 flv.js 实现播放。 我们还可以利用requestAnimationFrame 由浏览器来调度播放的速率,丢掉积累的帧,保持低延迟播放。
在网校教学场景中,从主讲端推流,到视频CND节点分发,最后到用户侧设备播放,这 3 个过程,哪一个是最耗时的?直播延迟,主要延在了哪一步?第 2 步。 第 2 步,采用 UDP 分发,甚至可以复用成熟多年、穿透能力强的 P2P 分发方案,保证从数据中心,低延迟分发各个运营商的边缘分发节点。这种分发方案避免了主要的分发延迟。 第 3 步,从边缘节点到用户设备,通过 WebSocket 连接边缘节点,使用 jsMpeg 播放 video1mpeg 视频流,延迟可以控制在 50ms。50ms 已经非常低了。
播放器如果要提供播放效率和秒开其实本质上是做好解复用(Demux),Demux是指解析视频的封装格式,得到包含的音视频原始码流,Demux时间越短,就越快得到视频流,从而加快秒开速度,实现我们想要的低延迟播放的效果
背景在比较同一个数据源,是RTMP播放延迟低还是RTSP延迟低之前,我们先看看RTMP和RTSP的区别,我们知道,RTMP(Real-Time Messaging Protocol)和RTSP(Real 它最初由Adobe Systems设计,用于在Flash播放器和流媒体服务器之间传输音频、视频和数据。RTMP以二进制形式传输数据,具有低延迟和高效传输的特点。 应用范围RTMP:RTMP因其低延迟和高效传输的特点,广泛应用于需要高性能实时流媒体传输的场景,如直播、视频聊天等。 ,用我们的RTMP推送、轻量级RTSP服务、RTMP|RTSP播放器,延迟基本上相差无几,可见,配好的推拉流服务模块,尤其关键。 单就延迟来看,如果好的RTMP或RTSP播放,二者差异不大,主要是看实际场景。以上是大概的比较,感兴趣的开发者,可以单独跟我沟通探讨。
技术背景 实际上,我们在2015年做Android平台RTSP、RTMP播放模块的时候,第一版就支持了多实例播放,因为SDK设计比较灵活,做个简单的player实例封装即可实现多实例播放(Android Unity的就有多路demo),所以官方一直没有正式demo,本次也是有个开发者提到,希望测试下我们多路播放的效果,自己又不想做封装,索性给做个版本。 技术实现 废话不多说,先上图: 我们针对的功能展示,主要是播放和录像这块,先说播放: /* * SmartPlayer.java * Author: daniusdk.com * Created 、录像的演示,除此之外,大牛直播SDK的RTSP、RTMP播放器海康实现播放缓冲设置、软硬解码设置、实时快照、实时音量调节、实时解码后数据回调等。 毫秒级延迟,完全满足对延迟、稳定性要求苛刻的场景下。感兴趣的开发者,可以单独和我沟通。
好多开发者在QT环境下实现RTMP或RTSP播放时,首先考虑到的是集成VLC,集成后,却发现VLC在延迟、断网重连、稳定性等各个方面不尽人意,无法满足上线环境需求。 本文以调用大牛直播SDK(官方)的Windows平台播放端SDK为例,介绍下如何在QT下实现低延迟的RTMP|RTSP播放器,废话不多说,先上图: QTPlayer.png 大牛直播SDK有MFC的demo ,所以在QT上实现播放轻车熟路,如果需要多窗口播放,也可以参考转发的demo,转发的那个4窗口预览的demo做了二次封装,调用更方便。 考虑到大多场景下,开发者有多路播放诉求,针对这种情况,我们对player做个简单的封装: 开始播放: bool player_wrapper::StartPlay(const std::string& play->OnWindowSize(widgets.at(i)->width(), widgets.at(i)->height()); } } } 以上是QT环境下集成个低延迟的
Flutter Engine使用C/C++编写,具有低延迟输入和高帧速率的特点,不像Unity3d一样,我们是回调YUV/RGB数据,在Unity3d里面绘制,Flutter直接调用native SDK 其次,客户和开发者驱动,Flutter发展至今,目前还没有个像样的RTSP或RTMP播放器,一个播放器,不是说,有个界面,有个开始、停止按钮就可以了,一个好用的直播播放器,对功能和性能属性要求很高,特别是稳定性和低延迟这块 async {
return _smartPlayerCallInt('setFastStartup', isFastStartup);
}
///
提供RTSP TCP/UDP模式设置及自动切换功能,适应不同网络环境,确保播放稳定性。 1.1.2 性能优化特性 内置低延迟模式,可将延迟控制在毫秒级别,满足实时性要求高的场景。 低延迟播放技术实现3.1 网络优化策略3.1.1 缓冲时间设置 将缓冲时间设置在几十毫秒到几百毫秒之间,减少数据缓冲带来的延迟,同时保证播放稳定性。 在Window/Android/iOS特定机型上支持H.264和H.265的硬件解码,充分发挥硬件性能,降低延迟。 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); //
本文是来自WWDC(苹果全球开发者大会) 2019的演讲,演讲的作者Roger Pantos,HLS的技术主管,本次演讲主题是介绍低延迟HTTP实时流(Low-Latency HLS)的实现和效果以及如何使用低延迟 在演讲的开始,Roger首先描述了低延迟对于体育直播、新闻、即时互动游戏广播以及颁奖典礼和其他社交媒体活动等的重要性。 介绍了低延迟HLS的设计目标是1-2秒,并且具有速率适配、加密、广告、元数据、向后兼容等功能。 然后Roger介绍了低延迟HLS如何实现上述的目标,与之前的HLS相比有5大变化:减少发布延时、优化段发现、消除段往返、减少播放列表传输开销、快速切换层。随后介绍了完成这5项变化的细节。 接着Roger展示了使用低延迟HLS视频通话的延迟,在AppleTV上美国用户与澳大利亚用户在视频通话时的延迟低于2秒。 最后Roger介绍了对于开发者来说,如何使用低延迟HLS进行项目开发。
当然,话说回来,如果是在特定的使用场景下,只需要某些版本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"); //设置是否启用低延迟模式
实时性:能够实现图像的实时传输,具有较低的延迟。这对于一些对实时性要求较高的应用场景,如直播、视频会议、无人机航拍等非常重要。 低延迟的无线图传可以让用户在接收端几乎同步地看到发送端的图像,提高交互性和用户体验。 一般来说,低功率的无线图传设备适用于短距离传输,如室内、小型活动场地等;而高功率的无线图传设备则可以用于长距离传输,如户外、大型活动现场等。 例如,在无人机航拍中,需要使用传输距离较远的无线图传设备,以便将无人机拍摄的画面实时传输到地面控制站。而在家庭监控中,短距离的无线图传设备就可以满足需求。 例如,一些采用先进的 LR-WiFi 技术或其他高性能无线通信技术的模块,能够在保证数据传输速率的同时,提升通信距离和抗干扰能力,为低延迟传输提供基础。
一、为什么“低延迟视频”在 2025 年突然变成刚需?过去十年里,“低延迟”这个词经常被用烂: 直播平台说自己低延迟; 安防摄像头说自己实时; 互动课堂说自己秒开不卡。 容错率越来越低 工业机器人撞一下货架,叫事故; 无人机晚避障 0.5 秒,可能就是真撞; 执法/巡检设备延迟太大,远程指挥就形同虚设。 所以,一个真正可用的低延迟 RTSP/RTMP 播放器,不再是“选项”,而是整个链路的关键一环。三、“超低延迟播放器”到底难在哪里? 真正可用的超低延迟播放器,必须在上述三层都做系统性设计,并且从一开始就以“低延迟”为目标,而不是后面再拧几个参数。2. 低延迟是“接管权”的前提 无人机多数时间按预设航线飞行,但一旦需要人工接管—— 延迟高,人就会产生“晕车感”; 延迟不稳定(时快时慢),操作员的判断会出现错配。
在无人机、四足机器人、远程施工、巡检等新兴场景中,一套可靠、低延迟、可嵌入头显设备的视频传输系统,正成为 AI 系统眼中的“关键器官”。 无人机远程巡检无人机不只是飞行平台,更是高空智能“观察者”。 ,构建起一个可插拔、低延迟、高并发、可控可调的视频播放能力闭环,特别适用于 Pico、Quest 等主流 VR 设备。 无需依赖外部播放器,开箱即用; 可动态切换源,适配巡检/多路视角切换场景。 四、 典型场景落地:头显 × 视频 × 控制的“远程闭环”场景类型视频方案价值 无人机图传通过 RTSP 推流,实时在 Pico 头显中低延迟预览,搭配陀螺仪控制视角,提升操作沉浸感 四足机器人巡检实时画面上屏
决定无人机能否成为低空经济的底层骨架的关键因素,是 能否构建起稳定、低延迟、可扩展的视频与数据链路。 例如,在长时电网巡检中,若无 低延迟的视频链路,巡检员无法在第一时间捕捉到线路上细微的异常(如火花、绝缘层破损、外物挂接)。大牛直播SDK通过 毫秒级的视频回传,让能源突破与巡检能力形成闭环。 跨平台解码与播放能力(Windows/Linux/Android/iOS),让车机系统、移动终端与后台指挥中心都能即时接入无人机画面,实现多端一致性体验。 在无人机表演中,SDK 的 低延迟播放器 确保后台实时监控队形与表演同步性。 4. ,离不开 低延迟视频链路与群体作业调度 的双重保障。
传统的单路播放器已无法满足此类需求,因此开发一个多路 RTSP 播放器显得尤为必要。该播放器主要面向以下场景: 视频监控中心 :对多个监控摄像头进行实时监控,要求低延迟、高稳定性。 is_hardware_decoder && is_enable_hardware_render_mode) { lib_player_.SmartPlayerSetHWRenderMode(get(), 1);}(二)低延迟模式为了满足实时性要求较高的场景 ,可以启用低延迟模式。 在 configurePlayer 方法中设置低延迟模式。 性能优化 :采用硬件加速、低延迟模式等技术手段,提高播放性能和实时性。 良好的资源管理 :合理管理播放器的生命周期和资源,避免内存泄漏和资源浪费。
在发布国产操作系统|Linux平台的RTMP|RTSP直播播放SDK之前,大牛直播SDK在Windows、Android、iOS平台已经有了非常成熟的技术积累,功能齐全、稳定性高、超低延迟、超低资源占用 、网络自动重连等,RTMP支持扩展H265播放, RTSP也支持H265播放。 Linux原生的RTSP、RTMP播放模块这里我们不做赘述,本文主要讲的是如何在Linux平台构建Unity下的RTSP和RTMP低延迟直播播放。 Unity侧,在Unity下完成绘制,这里就需要原生的RTMP、RTSP播放模块,拉流解码延迟非常低,数据投递效率非常高,无图无真相:Linux平台,我们是回调的YUV的数据,也就是 NT_SP_E_VIDEO_FRAME_FROMAT_I420 1 : 0); //设置是否启用低延迟模式//设置旋转角度(设置0, 90, 180, 270度有效,其他值无效)int rotate_degrees = 0;NTSmartPlayerSDK.NT_SP_SetRotation
目前该领域有两种技术:低延迟 HTTP 实时流媒体 (LL-HLS) 和基于 HTTP 的低延迟动态自适应流媒体 (LL-DASH)。 许多播放器支持 LL-HLS 和/或 LL-DASH 协议,包括 Apple 的 AVPlayer、Shaka 播放器、HLS.js Dash.js 等。本文致力于分析低延迟播放器和流媒体协议的性能。 低延迟自适应算法的其他变体可以在 LL-HLS 流播放器中找到,例如 HLS.js、Shaka 播放器 和 Apple 的 AVPlayer。 低延迟打包器的输出是分块的视频片段和清单文件,通知播放器如何在低延迟模式下使用流。 当延迟发生变化时,播放器必须比流的原生速度更快或更慢才能保持在流的实时边缘。表 4 中报告的播放速度变化数字证明了这一点。播放速度变化值越低,表示 QoE 越好。
需求很直接:变电站夜间值守薄弱、盲区多、报警后回看取证慢;希望一台巡检机器人替代夜巡,边走边看、实时回传、异常即告警。 周三,机器人上电跑通:前后左右与顶部共 10~12路1080P 摄像头接入,基于米尔 RK3576开发板 完成 硬件编解码 + RTSP/SRT 低延迟推流;端到端延迟稳定在120~150ms。 低延迟推流VPU 硬编 H.264/H.265 + RTP/RTSP(局域)或 SRT(跨公网),编码 80~100ms + 传输/解码 40~50ms。 06|结语巡检机器人需要移动、实时、可靠的视觉系统。 基于米尔 RK3576 的解决方案,以 多路摄像头 + 硬编硬解 + 低延迟推流 + 边缘AI 组合出一套可规模化复制的落地范式,从“能看”走向“看得准、传得稳、告得快”。
首先Bo介绍了低延迟DASH流是什么,其中,一个低延迟流,从编码器屏幕到播放器屏幕之间的延迟必须要低于5秒;视频片段会被分割成许多的块来进行编码传输;且低延迟的特性也决定了它在传输路径上不应有额外的缓冲 DASH-IF所提出的最新变动中,包含了这些特性:添加了许多重新同步的节点,来使流可以被独立地处理;增加了功能描述,来告知播放器应当如何在低延迟模式下进行工作。 Bo还介绍了在低延迟流中的前人工作,DVB低延迟DASH:使用GPAC软件实现的GPAC低延迟DASH;苹果的低延迟HLS,使用的是苹果服务器和IOS的音视频播放器,以及社区驱动的LHLS。 随后Bo展示了本次工作中低延迟DASH实现的DEMO的设置, ? 其中,编码器和播放器在波士顿区,而服务器则在西雅图。 最后Bo讨论了一些低延迟DASH的潜在问题,首先低延迟DASH的灵活性比传统的低延迟流要差;块的大小和延迟之间也存在着交换;低延迟DASH只支持HTTP/1.1。 最后附上演讲视频: