- 综合排序
- 最热优先
- 最新优先
- 来自专栏媒矿工厂
低延迟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.2K10发布于 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.4K20发布于 2021-01-25 - 来自专栏媒矿工厂
低延迟直播流技术
，但也因此会带来较大的延迟，因此低延迟也要在回放稳定性问题上进行权衡。 视频传输过程中往往对视频进行分段传输，因此，直播延迟也与视频分段的长度有关。 下面演讲者介绍了实现低延迟传输的方法。 实现低延迟最简单方法是，取用更短的视频片段，但是这会影响视频编码效率，同时也降低CDN缓冲的效率，带来更多的问题。 而更好的低延迟方法则是分块分发（Chunked delivery），对视频片段进行分块编码，分块传输，减弱片段长度对直播延迟的影响。 最后，演讲者还介绍了低延迟在MPEG-DASH以及Apple HLS协议中的整合，并介绍了低延迟传输的一些实际应用。
1.6K20发布于 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 芯片可能会专门针对低延迟应用进行优化，提供更好的性能。软件配置 操作系统和应用程序可以通过设置来启用低延迟模式。
44210编辑于 2024-11-12 - 来自专栏媒矿工厂
实时低延迟流式传输
本文来自BITMOVIN，由Jameson Steiner编辑，文章主要内容是“实时低延迟流式传输”。 什么是实时低延迟？ 实时流媒体的低延迟是指事件内容在媒体交付链的一端被捕获并在另一端向用户播放之间的时间延迟。 图1 端到端视频编码流程 低延迟是当前媒体行业最大的挑战之一，本文将深度探讨为什么需要关注低延迟。 为什么要关注低延迟？ 除了基础设施问题（例如未针对低延迟进行优化）之外，流传输方法还可能会因社交媒体源，推送通知等其他因素而导致延迟。 低延迟分块传输 低延迟分块传输除了带来低延迟，还有以下几点影响： 不断接收到的CMAF块流中，可以使客户端缓冲区级别更平滑，跳动更少。因此降低了缓冲区欠载的风险并提高了播放稳定性。
2.7K31发布于 2020-07-07 - 来自专栏音视频技术
Apple 低延迟HLS分析
低延迟HLS技术草案 2019年的WWDC上，Pantos宣布了最新的HLS草案，今年的变化旨在减少实时视频流的延迟。这个消息一出，业界反响很大，几家欢乐几家愁。 以上基本上就是这次苹果对低延迟HLS提出的技术草案，苹果也提供了参考实现用于测试和演示。 初步分析认为iOS13 beta里Apple还没有完全实现低延迟HLS的客户端功能。 ? ? ? ? AVPlayer的实现发现服务端对低延迟HLS支持不好的话，会自动切换回标准的HLS，让视频继续正常播放，所以测试低延迟HLS的时候只看视频是否能播放还不行，要抓包分析，确认低延迟HLS机制正常工作。 ，之前就有强力推动IPV6、HTTPS的先例，相信假以时日，Apple低延迟HLS也会成为业界标配。
4.6K63发布于 2019-07-01 - 来自专栏音视频技术
ALHLS：Apple低延迟HLS技术
在今年的WWDC上，Pantos宣布Apple更新了HLS，加入了新的低延迟模式。有趣的是，这不是第一次尝试着为低延迟HLS编写规范。 Apple的低延迟HLS（ALHLS） 首先，让我们看看Apple的低延迟HLS解决方案是如何工作的。你可以在这里观看演示并阅读说明。 我希望Apple会将此功能应用在无低延迟要求的链路当中，因为播放列表的臃肿是一个亟待解决的问题。 5. 为了从中获益，开发者将不得不实现所有功能，包括一些我没有提到的（如HTTP/2等）功能以实现符合预期的低延迟HLS流。 除了一些简单的新播放列表语义之外，LHLS使用与提供低延迟MPEG DASH-HTTP 1.1分块传输编码相同的策略。
2.1K30发布于 2019-07-04 - 来自专栏腾讯云音视频专家服务
低延迟直播的实现方法
直播实现低延迟，是对大部分直播产品的要求，也是提升直播产品用户体验最有效的一个方法。特别是体育赛事、直播互动、在线答题等场景对低延迟要求更高。今天简单跟大家介绍下如何直播如何实现低延迟。 、混流等产生的延迟 ④直播推流、CDN缓存和播放器缓存带来的延迟 数据流的编码/解码延迟和智能处理耗时都是毫秒级的延迟，直播延迟主要还是来源于网络传输和业务缓存。 通常RTMP/FLV协议延迟在1~3秒，这两种协议延迟的主要因素是上面说的网络传输延迟和GOP的大小，三种协议的比较如下： 直播协议 优点 缺点 播放延迟 FLV 成熟度高、高并发无压力 需集成 SDK ，就注定它不是低延迟直播的最佳解决方案。 4.png 5.png 小结 今天给大家介绍了如何判断直播延迟、延迟产生的原因、排查方法以及腾讯云快直播低延迟解决方案，相信在这个过程中大家已经对直播延迟有一定的理解，以后遇到直播延迟问题也知道从哪里入手
4.9K80发布于 2020-12-29 - 来自专栏阿利民
如何保证Android音频低延迟
为了更好的理解Android音频延迟产生的原因，最好将总的环路延迟分为以下两个部分： 应用延迟。Android开发者有很多能够降低延迟的方法，后面会逐步介绍 系统延迟。 不同的音频链路有不同延迟时间，比如内建麦克风、耳麦、蓝牙耳机之间的延迟都是不一样的，需要针对这些场景进行不同的处理。 使用蓝牙耳机至少增加100毫秒的延迟。 可以通过下面方法获取： AudioManager#PROPERTY_OUTPUT_FRAMES_PER_BUFFER 验证应用是否使用低延迟音轨 启动应用，然后运行下列命令： adb shell ps 如果您在“Name”列看到“F”，表示它在低延迟音轨上（F 代表快速音轨）。 最大限度缩短预热延迟时间 第一次将音频数据加入队列时，设备音频电路需要少量但仍不短的一段时间来预热。 所有专业音频、低延迟系统都使用“拉”机制。 开发者能做什么？ 不可否认的是，在系统层面的东西开发者确实很被动。
2.5K30编辑于 2022-05-16 - 来自专栏音视频技术
ALHLS：Apple低延迟HLS技术
在今年的WWDC上，Pantos宣布Apple更新了HLS，加入了新的低延迟模式。有趣的是，这不是第一次尝试着为低延迟HLS编写规范。 Apple的低延迟HLS（ALHLS） 首先，让我们看看Apple的低延迟HLS解决方案是如何工作的。你可以在这里观看演示并阅读说明。 我希望Apple会将此功能应用在无低延迟要求的链路当中，因为播放列表的臃肿是一个亟待解决的问题。 5. 为了从中获益，开发者将不得不实现所有功能，包括一些我没有提到的（如HTTP/2等）功能以实现符合预期的低延迟HLS流。 除了一些简单的新播放列表语义之外，LHLS使用与提供低延迟MPEG DASH-HTTP 1.1分块传输编码相同的策略。
1.6K10发布于 2019-07-12 - 来自专栏Linyb极客之路
低延迟系统的最佳实践
低延迟意味着更快的响应时间，更快的性能，以下最佳实践大部分来自于Quora等问题提炼： 1. 选择正确的语言 脚本语言不能使用，尽管它们可以运行得更快更快，当你寻找对几毫秒延迟都不能忍受时，就不能有解释语言的开销，你希望有一个强大的内存模型，能够无锁编程，可选语言有Java Scala和C 11 将一切放在内存中 I/O会杀死你的延迟，确保你所有的数据都在内存中，这就意味着你自己要管理你的数据结构，以及维护一个持久日志，这样，你才能在机器重新启动后重建原来内存状态，持久日志的选择有： Bitcask 让系统未充分利用 低延迟要求总是有资源能处理请求。不要试图让你的硬件/软件处于满负荷极限运行状态。留下一些头寸供使用。
1.2K20发布于 2018-09-27 - 来自专栏Android 开发者
打造低延迟互动音频: Oboe
“互动” 的感觉，低延迟、高互动的音频处理 (包括采集和回放) 有多重要。 如果您有玩音乐游戏，或者音乐软件 (如 DJ 或者合成器) 的话，绝对会对音频的延迟深恶痛绝——延迟不但会让您对自己的操作不再自信，更会摧毁一段被打磨了很久的旋律。 ? 如果您的应用希望用尽可能接近 “实时” 规格的低延迟采集或者播放音频，Oboe 绝对是不二之选。
1.5K20发布于 2018-12-13 - 来自专栏媒矿工厂
低广播延迟及实现协议
本文来自Elecard，作者是Vitaly Suturikhin，担任Elecard集成和技术支持部主管，主题是“低广播延迟及实现协议”。 在构建前端站和CDN的任何招标和竞赛中，低广播延迟已成为强制性要求。 低延迟不会降低信号传输的质量，这意味着在编码和多路复用时需要最小的缓冲，同时在任何设备的屏幕上保持平滑清晰的图像。 默认情况下，CMAF（例如HLS和MPEG DASH）不是为低延迟广播而设计的。但是，人们越来越关注低延迟，因此一些制造商提供了该标准的扩展，例如低延迟CMAF。 但是，在不兼容的情况下，播放器仍可以使用CMAF规范内的内容，并且具有HLS或DASH典型的标准延迟时间。 低延迟HLS 苹果在2019年6月发布了低延迟HLS规范。
1.8K50发布于 2020-07-07 - 来自专栏AIoT技术交流、分享
如何确保CAN网络低延迟通信
如果低优先级消息正在传输，高优先级消息会被挂起，直到低优先级消息传输完成。这可能导致高优先级消息的延迟，尤其是在总线负荷较重时。 帧长度： 数据帧的长度直接影响消息的传输时间。 3、延迟分析模型 为了深入了解延迟的影响，可以通过以下几个因素来分析： 传输延迟： 包括数据帧的传输时间、仲裁时间等。 这代表了消息传输的基础延迟。 仲裁延迟： 因为CAN采用优先级仲裁，消息的优先级和总线的负载情况会影响仲裁的延迟。在高负载情况下，低优先级消息可能需要等待较长时间才能访问总线。 4、优化低延迟通信的策略 为了确保CAN总线的低延迟通信，可以采取以下优化策略： 1. 优化消息优先级 CAN总线使用消息标识符（ID）决定消息的优先级，ID越小，优先级越高。 对低优先级的节点，可以适当增加发送周期，以减少对总线的占用。
47910编辑于 2025-02-18 - 来自专栏媒矿工厂
低延迟仍是一个挑战
本文来自streaming media的研讨会，主题是：低延迟仍然是一个挑战。主持人是流媒体视频联盟执行总监Jason Thibeault。 对编码器来说，开始可以不进行速率控制，用更少的比特率得到更低的延迟，因此会导致更短的关键帧间隔，也可以选择发送更多I帧。 4、有什么基本的工具和服务可以用于低延迟实时流? 因此需要把考虑用户的QOE，如果在延迟方面过于激进，可能导致回放卡顿，降低用户体验，因此需要在用户体验和低延迟上折中。 交付端是HTTP交付，从编码器到CDN再到播放器播放，延迟大约为1分半。但是由于TCP协议本身的ACK特性使它不适合大规模实现低延迟，应该选择基于UDP的协议，比如QUIC和SRT。 另外SRT是为了解决低延迟问题设计的基于UDP的协议，确保传输丢包可以重传，但是需要在接收端重建信号。 7、未来几年延迟可能降低的程度？
75460发布于 2020-06-24 - 来自专栏DeepHub IMBA
EfficientFormer:高效低延迟的Vision Transformers
最后以延迟为目标进行优化设计，获得一系列称为EfficientFormer的最终模型。最后还设计了EfficientFormerV2。 3、convn - bn比LN (GN)-Linear更有利于延迟，对于延迟的降低，精度的小损失是可以接受的。 4、非线性的延迟取决于硬件和编译器。 最后通过收集不同宽度的MB4D和MB3D的设备上延迟(16的倍数)，构建一个延迟查找表。 作者通过查找表计算每个动作产生的延迟，并评估每个动作的准确率下降。根据每延迟精度下降(-%/ms)选择动作。这个过程迭代地执行，直到达到目标延迟。 (细节见论文附录) 结果展示 ImageNet上与广泛使用的基于cnn的模型相比，EfficientFormer在准确率和延迟之间实现了更好的权衡。 传统的vit在延迟方面仍然表现不佳。
72820编辑于 2023-09-27 - 来自专栏媒矿工厂
使用Video Toolbox进行低延迟编码
本文来自苹果WWDC 2021，演讲者是苹果视频编码与处理团队的PeiKang Song，主要介绍了Video Toolbox中的低延迟编码模式，并对其API调用进行了简要说明。 低延迟的视频编码对很多视频应用场景（如实时视频通话等）都非常重要，而该模式旨在对目前实时应用中的编码架构进行优化。 首先，PeiKang Song对低延时视频编码技术进行了概述。 此外，低延时模式的视频编码器通常也会使用专门的硬件加速器，以降低能耗。值得注意的是，低延时模式支持的codec通常是H.264，并且该模式被引入到了iOS和macOS中。 除了低延迟以外，该模式还具备其他一些实时视频通信所需的特点： 1）new profiles：通过增加两个新的配置文件（CBP和CHP），该框架的互操作性得到了有效提高，CBP主要用于low-cost的场景
1.5K20发布于 2021-07-06 - 来自专栏媒矿工厂
低延迟DVB-DASH蓝皮书
蓝皮书简述 2019年10月，DVB在蓝皮书中发布了最新版本的DVB-DASH，并增加了低延迟模式。 低延迟模式是基于Internet的线性电视（特别是现场活动）交付的关键动力，它使得流媒体具有和广播相当的延迟。它还将通过插入互联网提供的内容来促进现场直播内容的个性化。 它还说明了如何实现低延迟交付和内容呈现。 面对的问题 由于传送网络的段长度和未知性能，DASH播放器中引入了Internet交付内容中的一些延迟。播放器采取的策略通常是缓冲多个段以减少卡顿的可能性。 也可以采用更短的段来实现更低的延迟。但是较短的段会使编码器更难高效工作，因此最终用户看到的视频质量会受影响。 提出的方案 DVB-DASH中针对低延迟的解决方案是将片段分成较小的块。 但是在低延迟模式下，当第一个块被传入CDN时，MPD会发出该段开始可用的时间信号。 ? 图1 低延迟DASH服务的基本信息流 播放器在其较早的可用时间从CDN请求片段，并且CDN交付第一个块。
1.3K20发布于 2019-10-21 - 来自专栏音视频技术
基于WebRTC的低延迟视频直播
Photo by Wendy Wei from Pexels 随着直播行业的迭代更新，传统直播方案的延迟问题越发凸显。 本文来自融云联合创始人、首席架构师 李淼在LiveVideoStackCon 2019深圳站中的演讲，在其中他详细介绍了如何利用WebRTC低延迟音视频传输的特点，解决传统直播方案的延迟问题。 WebRTC自身最大的优势：低延时、流量更少、性能好。 在低延迟直播的情况下，需要考虑在Gop下发后客户端需要能够快速追上主播端的发流，所以在观众感知不明显的情况下会对P祯和B祯就会采用1.1或1.2倍速下发，，直到所有包能够追上主播端或MCU端下推包的进程 ，后续在MCU合流完成后的整体时间即可同步，延迟会降到最低。
3.7K20发布于 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.1K10编辑于 2024-09-09
腾讯云开发者
