- 综合排序
- 最热优先
- 最新优先
- 来自专栏媒矿工厂
低延迟HLS
本文是来自WWDC(苹果全球开发者大会) 2019的演讲，演讲的作者Roger Pantos，HLS的技术主管，本次演讲主题是介绍低延迟HTTP实时流（Low-Latency HLS）的实现和效果以及如何使用低延迟 在演讲的开始，Roger首先描述了低延迟对于体育直播、新闻、即时互动游戏广播以及颁奖典礼和其他社交媒体活动等的重要性。 介绍了低延迟HLS的设计目标是1-2秒，并且具有速率适配、加密、广告、元数据、向后兼容等功能。 然后Roger介绍了低延迟HLS如何实现上述的目标，与之前的HLS相比有5大变化：减少发布延时、优化段发现、消除段往返、减少播放列表传输开销、快速切换层。随后介绍了完成这5项变化的细节。 接着Roger展示了使用低延迟HLS视频通话的延迟，在AppleTV上美国用户与澳大利亚用户在视频通话时的延迟低于2秒。 最后Roger介绍了对于开发者来说，如何使用低延迟HLS进行项目开发。
2.4K10发布于 2019-09-25 - 来自专栏媒矿工厂
低延迟DASH流
这次将介绍的是使用开放源代码工具的低延迟DASH流。 首先Bo介绍了低延迟DASH流是什么，其中，一个低延迟流，从编码器屏幕到播放器屏幕之间的延迟必须要低于5秒;视频片段会被分割成许多的块来进行编码传输;且低延迟的特性也决定了它在传输路径上不应有额外的缓冲 DASH-IF所提出的最新变动中，包含了这些特性：添加了许多重新同步的节点，来使流可以被独立地处理;增加了功能描述，来告知播放器应当如何在低延迟模式下进行工作。 Bo还介绍了在低延迟流中的前人工作，DVB低延迟DASH：使用GPAC软件实现的GPAC低延迟DASH;苹果的低延迟HLS，使用的是苹果服务器和IOS的音视频播放器，以及社区驱动的LHLS。 最后Bo讨论了一些低延迟DASH的潜在问题，首先低延迟DASH的灵活性比传统的低延迟流要差;块的大小和延迟之间也存在着交换;低延迟DASH只支持HTTP/1.1。 最后附上演讲视频：
1.6K20发布于 2021-01-25 - 来自专栏媒矿工厂
低延迟直播流技术
，但也因此会带来较大的延迟，因此低延迟也要在回放稳定性问题上进行权衡。 视频传输过程中往往对视频进行分段传输，因此，直播延迟也与视频分段的长度有关。 下面演讲者介绍了实现低延迟传输的方法。 而更好的低延迟方法则是分块分发（Chunked delivery），对视频片段进行分块编码，分块传输，减弱片段长度对直播延迟的影响。 最后，演讲者还介绍了低延迟在MPEG-DASH以及Apple HLS协议中的整合，并介绍了低延迟传输的一些实际应用。 更为详细的内容请看视频： http://mpvideo.qpic.cn/0bf2heaakaaa3aaghxnw4bpfaoodau4qabia.f10002.mp4?
1.9K20发布于 2020-05-20 - 来自专栏RTSP/RTMP直播相关
Android音视频直播低延迟探究之：WLAN低延迟模式
Android WLAN低延迟模式Android WLAN低延迟模式是 Android 10 引入的一种功能，允许对延迟敏感的应用将 Wi-Fi 配置为低延迟模式，以减少网络延迟，启动条件如下：Wi-Fi “LOW_LATENCY”： 表示低延迟。低延迟对于一些对实时性要求较高的应用非常重要，例如在线游戏、视频会议、实时流媒体等。 在这种模式下，Wi-Fi 连接会尽量减少数据传输的延迟时间，以确保快速响应和流畅的交互体验。二、可能的应用场景在线游戏 对于竞技类在线游戏，低延迟是至关重要的。 实时流媒体 对于观看实时体育赛事、音乐会等流媒体内容，低延迟可以减少缓冲时间，提供更即时的观看体验。三、实现方式硬件支持 设备的 Wi-Fi 芯片和天线需要支持低延迟功能。 一些高端的 Wi-Fi 芯片可能会专门针对低延迟应用进行优化，提供更好的性能。软件配置 操作系统和应用程序可以通过设置来启用低延迟模式。
93810编辑于 2024-11-12 - 来自专栏音视频技术
Apple 低延迟HLS分析
低延迟HLS技术草案 2019年的WWDC上，Pantos宣布了最新的HLS草案，今年的变化旨在减少实时视频流的延迟。这个消息一出，业界反响很大，几家欢乐几家愁。 以上基本上就是这次苹果对低延迟HLS提出的技术草案，苹果也提供了参考实现用于测试和演示。 低延迟HLS demo 为了让参考实现跑起来，需要架设一个支持http2、https、php的服务器，首先尝试了MAMP最新版带的apache，发现缺少http2模块，需要自己编译一个apache，感觉比较麻烦 分析总结 demo告一段落，评估一下要想应用到实际生产环境中的成本，发现还有不少注意点和难点： 源站要提供HTTP / 2支持，因为低延迟HLS依赖多个HTTP / 2特性：多流控制，H2推送和H2 Ping AVPlayer的实现发现服务端对低延迟HLS支持不好的话，会自动切换回标准的HLS，让视频继续正常播放，所以测试低延迟HLS的时候只看视频是否能播放还不行，要抓包分析，确认低延迟HLS机制正常工作。
5K63发布于 2019-07-01 - 来自专栏媒矿工厂
实时低延迟流式传输
本文来自BITMOVIN，由Jameson Steiner编辑，文章主要内容是“实时低延迟流式传输”。 什么是实时低延迟？ 图1 端到端视频编码流程 低延迟是当前媒体行业最大的挑战之一，本文将深度探讨为什么需要关注低延迟。 为什么要关注低延迟？ 高延迟是最低的需求，而实时是最高的要求。可以参阅图2延迟频谱（包括延迟类型，延迟时间和流格式）： ? 低延迟分块传输 低延迟分块传输除了带来低延迟，还有以下几点影响： 不断接收到的CMAF块流中，可以使客户端缓冲区级别更平滑，跳动更少。因此降低了缓冲区欠载的风险并提高了播放稳定性。 例如，第二个段的段可用性开始时间为AST + segment_duration * 2。 低延迟流与MPEG-DASH 前文描述了分块编码和传输如何允许对仍在编码过程中的片段进行部分加载和使用。
3.1K31发布于 2020-07-07 - 来自专栏音视频技术
ALHLS：Apple低延迟HLS技术
在今年的WWDC上，Pantos宣布Apple更新了HLS，加入了新的低延迟模式。有趣的是，这不是第一次尝试着为低延迟HLS编写规范。 而当需要低延迟传送时，这些传统HTTP请求的开支将成为决定“Well-Clock”延迟下限的重要条件。 Apple解决此问题的新方法是，使用HTTP/2推送那些在播放列表请求响应中较短的媒体“部件”。 为了从中获益，开发者将不得不实现所有功能，包括一些我没有提到的（如HTTP/2等）功能以实现符合预期的低延迟HLS流。 我们必须假设Apple有一种方法可以在使用HTTP/2时，在自己的设备上测量下载性能，原因如下： 1. 这是Apple实现让低延迟策略与自适应码律一起工作的唯一方式，并且...... 2. HTTP/2是一项年轻的技术，使用它的工具非常有限，同时浏览器中的Web API也不够成熟，无法在现有应用之上构建低延迟流技术。
2.3K30发布于 2019-07-04 - 来自专栏腾讯云音视频专家服务
低延迟直播的实现方法
直播实现低延迟，是对大部分直播产品的要求，也是提升直播产品用户体验最有效的一个方法。特别是体育赛事、直播互动、在线答题等场景对低延迟要求更高。今天简单跟大家介绍下如何直播如何实现低延迟。 才能播放 2s - 3s RTMP 优质线路下理论延迟最低 高并发情况下表现不佳 1s - 3s HLS(m3u8) 手机浏览器支持度高 延迟非常高 10s - 30s FLV延迟一般在2-10秒左右 ，就注定它不是低延迟直播的最佳解决方案。 检查推流端设置 如果发现在播放端延迟比较大，注意把关键帧间隔设置为1秒或2秒，也可以换用腾讯云的推流Demo对比下，排查看是不是推流端的编码缓存导致的延迟。 4.png 5.png 小结 今天给大家介绍了如何判断直播延迟、延迟产生的原因、排查方法以及腾讯云快直播低延迟解决方案，相信在这个过程中大家已经对直播延迟有一定的理解，以后遇到直播延迟问题也知道从哪里入手
5.5K80发布于 2020-12-29 - 来自专栏阿利民
如何保证Android音频低延迟
为了更好的理解Android音频延迟产生的原因，最好将总的环路延迟分为以下两个部分： 应用延迟。Android开发者有很多能够降低延迟的方法，后面会逐步介绍 系统延迟。 不同的音频链路有不同延迟时间，比如内建麦克风、耳麦、蓝牙耳机之间的延迟都是不一样的，需要针对这些场景进行不同的处理。 使用蓝牙耳机至少增加100毫秒的延迟。 可以通过下面方法获取： AudioManager#PROPERTY_OUTPUT_FRAMES_PER_BUFFER 验证应用是否使用低延迟音轨 启动应用，然后运行下列命令： adb shell ps 如果您在“Name”列看到“F”，表示它在低延迟音轨上（F 代表快速音轨）。 最大限度缩短预热延迟时间 第一次将音频数据加入队列时，设备音频电路需要少量但仍不短的一段时间来预热。 所有专业音频、低延迟系统都使用“拉”机制。 开发者能做什么？ 不可否认的是，在系统层面的东西开发者确实很被动。
3K30编辑于 2022-05-16 - 来自专栏Android 开发者
打造低延迟互动音频: Oboe
“互动” 的感觉，低延迟、高互动的音频处理 (包括采集和回放) 有多重要。 如果您有玩音乐游戏，或者音乐软件 (如 DJ 或者合成器) 的话，绝对会对音频的延迟深恶痛绝——延迟不但会让您对自己的操作不再自信，更会摧毁一段被打磨了很久的旋律。 ? 如果您的应用希望用尽可能接近 “实时” 规格的低延迟采集或者播放音频，Oboe 绝对是不二之选。
1.7K20发布于 2018-12-13 - 来自专栏Linyb极客之路
低延迟系统的最佳实践
低延迟意味着更快的响应时间，更快的性能，以下最佳实践大部分来自于Quora等问题提炼： 1. 选择正确的语言 脚本语言不能使用，尽管它们可以运行得更快更快，当你寻找对几毫秒延迟都不能忍受时，就不能有解释语言的开销，你希望有一个强大的内存模型，能够无锁编程，可选语言有Java Scala和C 11 2. 将一切放在内存中 I/O会杀死你的延迟，确保你所有的数据都在内存中，这就意味着你自己要管理你的数据结构，以及维护一个持久日志，这样，你才能在机器重新启动后重建原来内存状态，持久日志的选择有： Bitcask 让系统未充分利用 低延迟要求总是有资源能处理请求。不要试图让你的硬件/软件处于满负荷极限运行状态。留下一些头寸供使用。
1.3K20发布于 2018-09-27 - 来自专栏音视频技术
ALHLS：Apple低延迟HLS技术
在今年的WWDC上，Pantos宣布Apple更新了HLS，加入了新的低延迟模式。有趣的是，这不是第一次尝试着为低延迟HLS编写规范。 而当需要低延迟传送时，这些传统HTTP请求的开支将成为决定“Well-Clock”延迟下限的重要条件。 Apple解决此问题的新方法是，使用HTTP/2推送那些在播放列表请求响应中较短的媒体“部件”。 为了从中获益，开发者将不得不实现所有功能，包括一些我没有提到的（如HTTP/2等）功能以实现符合预期的低延迟HLS流。 我们必须假设Apple有一种方法可以在使用HTTP/2时，在自己的设备上测量下载性能，原因如下： 1. 这是Apple实现让低延迟策略与自适应码律一起工作的唯一方式，并且...... 2. HTTP/2是一项年轻的技术，使用它的工具非常有限，同时浏览器中的Web API也不够成熟，无法在现有应用之上构建低延迟流技术。
1.8K10发布于 2019-07-12 - 来自专栏媒矿工厂
低广播延迟及实现协议
在构建前端站和CDN的任何招标和竞赛中，低广播延迟已成为强制性要求。 低延迟不会降低信号传输的质量，这意味着在编码和多路复用时需要最小的缓冲，同时在任何设备的屏幕上保持平滑清晰的图像。 默认情况下，CMAF（例如HLS和MPEG DASH）不是为低延迟广播而设计的。但是，人们越来越关注低延迟，因此一些制造商提供了该标准的扩展，例如低延迟CMAF。 图3.标准和分段的CMAF 要在配置文件之间切换，需要缓冲（最少2秒）。考虑到这一点以及潜在的交付问题，该标准的开发者声称潜在延迟少于3秒。 但是，在不兼容的情况下，播放器仍可以使用CMAF规范内的内容，并且具有HLS或DASH典型的标准延迟时间。 低延迟HLS 苹果在2019年6月发布了低延迟HLS规范。
2K50发布于 2020-07-07 - 来自专栏AIoT技术交流、分享
如何确保CAN网络低延迟通信
如果低优先级消息正在传输，高优先级消息会被挂起，直到低优先级消息传输完成。这可能导致高优先级消息的延迟，尤其是在总线负荷较重时。 帧长度： 数据帧的长度直接影响消息的传输时间。 2、实时性要求 在一些关键应用中，如汽车安全系统、工业自动化等，CAN网络的实时性要求十分严格。 这代表了消息传输的基础延迟。 仲裁延迟： 因为CAN采用优先级仲裁，消息的优先级和总线的负载情况会影响仲裁的延迟。在高负载情况下，低优先级消息可能需要等待较长时间才能访问总线。 4、优化低延迟通信的策略 为了确保CAN总线的低延迟通信，可以采取以下优化策略： 1. 优化消息优先级 CAN总线使用消息标识符（ID）决定消息的优先级，ID越小，优先级越高。 2. 减少消息长度 较长的数据帧会导致较长的传输时间，从而增加延迟。 在设计CAN消息时，应尽量减少数据帧的长度。
79410编辑于 2025-02-18 - 来自专栏媒矿工厂
低延迟仍是一个挑战
用户更在意端到端延迟，比如他们希望在游戏过程中可以更快地做出决策。 2、什么是cache miss? 如何在延迟工作流中提升cache的效果？硬件有什么作用？ 因此需要把考虑用户的QOE，如果在延迟方面过于激进，可能导致回放卡顿，降低用户体验，因此需要在用户体验和低延迟上折中。 利用WebRTC技术进行P2P通信，分发端的技术可以帮助降低延迟，并且提供交互体验。总体而言，目前没有一种统工具包可以完成所有降低延迟的操作，而且这些操作会影响视频回放的质量。 6、应该选择什么传输协议来有效降低延迟？ Rob举例说可以用WebRTC的通道传输HLS实现P2P连接，这样所有人都可以看到高质量的电影视频。如果要达到超低延迟一般不使用CDN。 另外SRT是为了解决低延迟问题设计的基于UDP的协议，确保传输丢包可以重传，但是需要在接收端重建信号。 7、未来几年延迟可能降低的程度？
87560发布于 2020-06-24 - 来自专栏DeepHub IMBA
EfficientFormer:高效低延迟的Vision Transformers
最后以延迟为目标进行优化设计，获得一系列称为EfficientFormer的最终模型。最后还设计了EfficientFormerV2。 延迟分析 作者在论文中发现: 1、内核大、步幅大的补丁嵌入是移动设备上的速度瓶颈。 2、一致的特征维度对于令牌混合器的选择很重要。MHSA不一定是速度瓶颈。 在网络的S1和S2中，每个区块可以选择MB4D或I，在S3和S4中，每个区块可以选择MB3D、MB4D或I。 在最后两个阶段只启用MB3D的原因有2个：1、由于MHSA的计算相对于令牌长度呈二次增长，因此在早期阶段将其集成将大大增加计算成本。2、网络的早期阶段捕获低级特征，而后期阶段学习长期依赖关系。 对于S1和S2, n∈{4D, I}，对于S3和S4, n∈{4D, 3D, I}。 最后通过收集不同宽度的MB4D和MB3D的设备上延迟(16的倍数)，构建一个延迟查找表。
90320编辑于 2023-09-27 - 来自专栏媒矿工厂
使用Video Toolbox进行低延迟编码
本文来自苹果WWDC 2021，演讲者是苹果视频编码与处理团队的PeiKang Song，主要介绍了Video Toolbox中的低延迟编码模式，并对其API调用进行了简要说明。 低延迟的视频编码对很多视频应用场景（如实时视频通话等）都非常重要，而该模式旨在对目前实时应用中的编码架构进行优化。 此外，低延时模式的视频编码器通常也会使用专门的硬件加速器，以降低能耗。值得注意的是，低延时模式支持的codec通常是H.264，并且该模式被引入到了iOS和macOS中。 除了低延迟以外，该模式还具备其他一些实时视频通信所需的特点： 1）new profiles：通过增加两个新的配置文件（CBP和CHP），该框架的互操作性得到了有效提高，CBP主要用于low-cost的场景 2）temporal scalability：当有多个接收者存在时，时域可伸缩可以有效提高框架的有效性。即使各个接收方的接收能力不同，发送端也只需要编码一次产生单一码流。
1.7K20发布于 2021-07-06 - 来自专栏媒矿工厂
低延迟DVB-DASH蓝皮书
蓝皮书简述 2019年10月，DVB在蓝皮书中发布了最新版本的DVB-DASH，并增加了低延迟模式。 低延迟模式是基于Internet的线性电视（特别是现场活动）交付的关键动力，它使得流媒体具有和广播相当的延迟。它还将通过插入互联网提供的内容来促进现场直播内容的个性化。 它还说明了如何实现低延迟交付和内容呈现。 面对的问题 由于传送网络的段长度和未知性能，DASH播放器中引入了Internet交付内容中的一些延迟。播放器采取的策略通常是缓冲多个段以减少卡顿的可能性。 也可以采用更短的段来实现更低的延迟。但是较短的段会使编码器更难高效工作，因此最终用户看到的视频质量会受影响。 提出的方案 DVB-DASH中针对低延迟的解决方案是将片段分成较小的块。 但是在低延迟模式下，当第一个块被传入CDN时，MPD会发出该段开始可用的时间信号。 ? 图1 低延迟DASH服务的基本信息流 播放器在其较早的可用时间从CDN请求片段，并且CDN交付第一个块。
1.4K20发布于 2019-10-21 - 来自专栏音视频技术
基于WebRTC的低延迟视频直播
本文来自融云联合创始人、首席架构师 李淼在LiveVideoStackCon 2019深圳站中的演讲，在其中他详细介绍了如何利用WebRTC低延迟音视频传输的特点，解决传统直播方案的延迟问题。 WebRTC自身最大的优势：低延时、流量更少、性能好。 首先了解p2p通讯或者多人音视频通讯与直播通讯的差异是什么： 观众人数的差异。 2. WebRTC直播的过程 WebRTC支持低延时直播，那么如何通过WebRTC来完成直播场景的构建呢？ 在低延迟直播的情况下，需要考虑在Gop下发后客户端需要能够快速追上主播端的发流，所以在观众感知不明显的情况下会对P祯和B祯就会采用1.1或1.2倍速下发，，直到所有包能够追上主播端或MCU端下推包的进程
4.1K20发布于 2021-09-01 - 来自专栏RTSP/RTMP直播相关
同样数据源走RTMP播放延迟低还是RTSP低？
背景在比较同一个数据源，是RTMP播放延迟低还是RTSP延迟低之前，我们先看看RTMP和RTSP的区别，我们知道，RTMP（Real-Time Messaging Protocol）和RTSP（Real RTMP以二进制形式传输数据，具有低延迟和高效传输的特点。RTSP：RTSP则是一种控制流媒体会话的协议，它不直接传输媒体数据本身，而是负责描述流媒体会话，并指示客户端如何获取流媒体数据。 应用范围RTMP：RTMP因其低延迟和高效传输的特点，广泛应用于需要高性能实时流媒体传输的场景，如直播、视频聊天等。 终端采集屏幕数据，然后，同时推RTMP服务和启动轻量级RTSP服务，对外提供RTSP拉流的url，实际看到的实验结果如下：可以看到，用我们的RTMP推送、轻量级RTSP服务、RTMP|RTSP播放器，延迟基本上相差无几 单就延迟来看，如果好的RTMP或RTSP播放，二者差异不大，主要是看实际场景。以上是大概的比较，感兴趣的开发者，可以单独跟我沟通探讨。
1.5K10编辑于 2024-09-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号