- 综合排序
- 最热优先
- 最新优先
- 来自专栏媒矿工厂
实时低延迟流式传输
本文来自BITMOVIN，由Jameson Steiner编辑，文章主要内容是“实时低延迟流式传输”。 什么是实时低延迟？ 图1 端到端视频编码流程 低延迟是当前媒体行业最大的挑战之一，本文将深度探讨为什么需要关注低延迟。 为什么要关注低延迟？ 这时候延迟会使得用户体验变差，因为用户知道自己喜欢的球队肯定输了。因此越来越低的实时延迟需求已变得显而易见，在如今的数字世界中，广播和流传输之间的延迟差异是无法接受的。 除了基础设施问题（例如未针对低延迟进行优化）之外，流传输方法还可能会因社交媒体源，推送通知等其他因素而导致延迟。 低延迟分块传输 低延迟分块传输除了带来低延迟，还有以下几点影响： 不断接收到的CMAF块流中，可以使客户端缓冲区级别更平滑，跳动更少。因此降低了缓冲区欠载的风险并提高了播放稳定性。
3.1K31发布于 2020-07-07 - 来自专栏全栈程序员必看
低延迟视频传输_网络延时
本文的话题有关音视频传输优化，优化目标： 低卡顿率，超流畅。 秒互动，超低延时。 超高清。 优化要点不外乎： 音视频传输优化不能基于TCP/QUIC。 音视频传输优化需要对高清做柔性。 如TCP，QUIC类通用传输协议不适合传输音视频，更无助于其传输优化，极致体验需在音视频流中自行斟酌传输细节。 昨天(2月25日)的”火山引擎视频云科技原力峰会”上，提到火山引擎，腾讯云，阿里云三家联合发布了《超低延时直播协议信令标准》，依次标准，火山引擎宣称延迟控制在1s以内，但就在前几天的2月22日，腾讯云发布了 通用协议不理解传输细节，如TCP只是死磕确保传输每一个字节，即便允许不可靠，也不晓得丢弃哪一个包。若音视频协议自行做传输控制，就是另一局面。 当音视频传输优化很难进行下去时，不妨换个思路，与其费劲纠结于低卡顿，低延时，高清晰度如何实现，不如看看能放弃些什么。人们绞尽脑汁设计的那些个复杂无比且脆弱并且不一定有效的算法真的必要吗？
1K20编辑于 2022-11-10 - 来自专栏音视频技术
（超）低延迟视频流传输的未来
每个视频传输协议都有其优点和缺点，并适用于不同的应用场景。 在本文中，我们总结了四种主要的低延迟协议，探讨它们的优点和缺点，并给出了我们对于这些协议未来发展的评论。 因此在2020年4月，Apple终于实现了LL-HLS（低延迟HLS）——基于HLS协议的扩展；在维持HLS自身的可扩展性的同时，还可以利用子切片和这些切片的动态传输实现低延迟视频和直播。 与其他低延迟协议相比，HESP最大的区别是它依赖两个（而非一个）视频流。在了解HESP如何帮助我们达到次秒级延迟之前，让我们先来聊聊视频流传输所使用到的不同类型的帧。 如果延迟对你的业务而言非常重要，你应该了解一下低延迟和超低延迟协议，如果你只需要延迟在2秒左右（适用于体育赛事、音乐会和在线课堂）的单向实时视频传输性能，而又没有太多的预算，你应该了解一下HLS和（或） 在api.video，我们非常相信，基于HTTP的低延迟或超低延迟流媒体传输协议将在最后赢得这场“战斗”。
1.8K20编辑于 2022-06-20 - 来自专栏音视频技术
吴涛 ：低延迟传输协议和新Codec将成为热点
吴涛：我已经在音视频编解码、传输领域工作10多年的时间，曾经在广电集团 工作，现在在陌 陌视频部主要负责直播媒体技术方面的工作。 平时对音视频编解码、低延迟大量数据传输、超分辨率比较关注。 吴涛：在2018年，低延迟传输协议、新的编码压缩方式都将成为热门。
53040发布于 2021-09-01 - 来自专栏txp玩Linux
嵌入式音视频低延迟传输协议srt
一、简介： SRT(Secure Reliable Transport，安全可靠传输）是一种用于超低（亚秒）延迟的实时音视频流及通用批量数据传输的传输协议。 SRT解决了复杂的传输时序问题，可以做到支持高吞吐量文件和超清视频的实时传输。 2.2.低延迟： 为了适应用户的各种部署环境，因此SRT的流错误纠正策略是可配置的。由于SRT建立在UDP协议之上，解决了TCP协议传输延迟高的问题。 除了上述两种场景外，还有一种视频直播的场景，就是同时要求低延时和大并发的场景，比如赛事直播、股票信息同步、大班教育等。SRT可以很好地满足上述场景的要求。 SRT端点建立了稳定的端到端延迟概要，消除了下游设备需要有自己的缓冲区来应对不断变化的信号延迟。信号时间准确。 文章参考：http://t.csdn.cn/dNAbY
1.7K10编辑于 2023-09-12 - 来自专栏媒矿工厂
低延迟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 - 来自专栏RTSP/RTMP直播相关
无线图传下的低延迟视频传输播放技术探讨
例如，在安防监控领域，无线图传可以将不同位置的监控摄像头的图像传输到监控中心，并且可以根据需要随时增加或调整摄像头的位置和数量。 实时性：能够实现图像的实时传输，具有较低的延迟。 低延迟的无线图传可以让用户在接收端几乎同步地看到发送端的图像，提高交互性和用户体验。 一般来说，低功率的无线图传设备适用于短距离传输，如室内、小型活动场地等；而高功率的无线图传设备则可以用于长距离传输，如户外、大型活动现场等。 例如，一些采用先进的 LR-WiFi 技术或其他高性能无线通信技术的模块，能够在保证数据传输速率的同时，提升通信距离和抗干扰能力，为低延迟传输提供基础。 硬件编解码相比软件编解码具有更高的效率和更低的延迟，能够快速处理视频数据，减少处理时间，从而降低整体传输延迟。
1.4K10编辑于 2024-11-25 - 来自专栏音视频技术
低延迟音视频传输技术在直播领域的应用
今天我向大家分享的主要内容有： 基于CDN架构的直播应用 基于CDN架构的低延迟直播的应用 CDN架构下非交互直播的问题 带有交互能力的直播 直播技术未来的发展 1.基于CDN架构的直播应用 这张图是陌陌 2）抗延迟 为什么用户给主播发消息给主播，隔了好厂一段时间才有反馈？因为直播画面存在延迟。卡顿与延迟是互相矛盾的条件，画面流畅意味着可能延迟增大，延迟减小画面又可能会因为网络不稳定等原因出现卡顿。 2.基于CDN架构的低延迟直播的应用 讲完了CDN架构的简单应用，接下来讲一讲年初最火的直播答题。这张图是陌陌的一个直播答题界面，直播答题实际上有什么难点呢？ 5.直播技术未来的发展 5.1 低卡顿 为什么说是“低卡顿”而不是说“无卡顿”？因为现有的技术还无法实现完全没有卡顿、缓冲。这不单单取决于技术，更包括基础设施的建设，我们只是希望把卡顿率降到最低。 5.2 低延迟 实现低延迟可以通过使用更好的传输协议，因为多媒体本身是适用于UDP协议而非TCP协议的。
1.3K20发布于 2021-09-01 - 来自专栏媒矿工厂
低延迟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 - 来自专栏媒矿工厂
低延迟直播流技术
，但也因此会带来较大的延迟，因此低延迟也要在回放稳定性问题上进行权衡。 视频传输过程中往往对视频进行分段传输，因此，直播延迟也与视频分段的长度有关。 下面演讲者介绍了实现低延迟传输的方法。 实现低延迟最简单方法是，取用更短的视频片段，但是这会影响视频编码效率，同时也降低CDN缓冲的效率，带来更多的问题。 而更好的低延迟方法则是分块分发（Chunked delivery），对视频片段进行分块编码，分块传输，减弱片段长度对直播延迟的影响。 最后，演讲者还介绍了低延迟在MPEG-DASH以及Apple HLS协议中的整合，并介绍了低延迟传输的一些实际应用。
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 芯片可能会专门针对低延迟应用进行优化，提供更好的性能。软件配置 操作系统和应用程序可以通过设置来启用低延迟模式。
93510编辑于 2024-11-12 - 来自专栏音视频技术
Apple 低延迟HLS分析
低延迟HLS技术草案 2019年的WWDC上，Pantos宣布了最新的HLS草案，今年的变化旨在减少实时视频流的延迟。这个消息一出，业界反响很大，几家欢乐几家愁。 以上基本上就是这次苹果对低延迟HLS提出的技术草案，苹果也提供了参考实现用于测试和演示。 初步分析认为iOS13 beta里Apple还没有完全实现低延迟HLS的客户端功能。 ? ? ? ? AVPlayer的实现发现服务端对低延迟HLS支持不好的话，会自动切换回标准的HLS，让视频继续正常播放，所以测试低延迟HLS的时候只看视频是否能播放还不行，要抓包分析，确认低延迟HLS机制正常工作。 ，之前就有强力推动IPV6、HTTPS的先例，相信假以时日，Apple低延迟HLS也会成为业界标配。
5K63发布于 2019-07-01 【软考 网络性能分析】传输时间+传输延迟
传输时间是指将数据包的所有比特发送到链路上所需的时间，而传播延迟是指信号在介质中从发送端传输到接收端所需的时间。 关键概念 传输时间：将数据包所有比特发送到链路上所需的时间 传播延迟：信号在介质中从发送端传输到接收端所需的时间 总时间 = 传输时间 + 传播延迟 计算过程 1. 总时间计算 总时间 = 传输时间 + 传播延迟 = 62.5 ms + 10 ms = 72.5 ms 答案 正确答案：72.5ms 相关题型案例 案例1：基本传输计算 问题：相距1000公里的两地之间传输一个 问题：相距5000公里的两地之间传输一个10000比特的数据包，数据速率为1Mb/s，处理延迟为2ms，求总时间。 解答： 传输时间 = 10000 / 1000000 = 10 ms 传播延迟 = 5000 / 200000 = 25 ms 总时间 = 10 + 25 + 2 = 37 ms 案例3：带宽延迟积 问题
19410编辑于 2026-01-23- 来自专栏音视频技术
ALHLS：Apple低延迟HLS技术
虽然HLS具有简单、易扩展等优势，但当被用于实时流式传输时，很容易出现高延迟问题。 在今年的WWDC上，Pantos宣布Apple更新了HLS，加入了新的低延迟模式。有趣的是，这不是第一次尝试着为低延迟HLS编写规范。 Apple的低延迟HLS（ALHLS） 首先，让我们看看Apple的低延迟HLS解决方案是如何工作的。你可以在这里观看演示并阅读说明。 除了一些简单的新播放列表语义之外，LHLS使用与提供低延迟MPEG DASH-HTTP 1.1分块传输编码相同的策略。 然而，随着DASH对低延迟流媒体的LHLS风格分块传输交付的持续标准化，现在看来Apple正通过强化ALHLS的应用，迫使我们回到封闭的交付堆栈策略。
1.8K10发布于 2019-07-12 - 来自专栏Linyb极客之路
低延迟系统的最佳实践
低延迟意味着更快的响应时间，更快的性能，以下最佳实践大部分来自于Quora等问题提炼： 1. 选择正确的语言 脚本语言不能使用，尽管它们可以运行得更快更快，当你寻找对几毫秒延迟都不能忍受时，就不能有解释语言的开销，你希望有一个强大的内存模型，能够无锁编程，可选语言有Java Scala和C 11 将一切放在内存中 I/O会杀死你的延迟，确保你所有的数据都在内存中，这就意味着你自己要管理你的数据结构，以及维护一个持久日志，这样，你才能在机器重新启动后重建原来内存状态，持久日志的选择有： Bitcask 让系统未充分利用 低延迟要求总是有资源能处理请求。不要试图让你的硬件/软件处于满负荷极限运行状态。留下一些头寸供使用。
1.3K20发布于 2018-09-27 - 来自专栏Android 开发者
打造低延迟互动音频: Oboe
“互动” 的感觉，低延迟、高互动的音频处理 (包括采集和回放) 有多重要。 如果您有玩音乐游戏，或者音乐软件 (如 DJ 或者合成器) 的话，绝对会对音频的延迟深恶痛绝——延迟不但会让您对自己的操作不再自信，更会摧毁一段被打磨了很久的旋律。 ? 如果您的应用希望用尽可能接近 “实时” 规格的低延迟采集或者播放音频，Oboe 绝对是不二之选。
1.7K20发布于 2018-12-13 - 来自专栏音视频技术
ALHLS：Apple低延迟HLS技术
虽然HLS具有简单、易扩展等优势，但当被用于实时流式传输时，很容易出现高延迟问题。 在今年的WWDC上，Pantos宣布Apple更新了HLS，加入了新的低延迟模式。有趣的是，这不是第一次尝试着为低延迟HLS编写规范。 Apple的低延迟HLS（ALHLS） 首先，让我们看看Apple的低延迟HLS解决方案是如何工作的。你可以在这里观看演示并阅读说明。 除了一些简单的新播放列表语义之外，LHLS使用与提供低延迟MPEG DASH-HTTP 1.1分块传输编码相同的策略。 然而，随着DASH对低延迟流媒体的LHLS风格分块传输交付的持续标准化，现在看来Apple正通过强化ALHLS的应用，迫使我们回到封闭的交付堆栈策略。
2.3K30发布于 2019-07-04 - 来自专栏腾讯云音视频专家服务
低延迟直播的实现方法
直播实现低延迟，是对大部分直播产品的要求，也是提升直播产品用户体验最有效的一个方法。特别是体育赛事、直播互动、在线答题等场景对低延迟要求更高。今天简单跟大家介绍下如何直播如何实现低延迟。 1、传输和访问延时 我们都知道数据在网络中传输，经过不同的地域不同的物理设备难免会造成延迟，如果在相同带宽环境下播放端距离推流端距离越近延迟就会越小，传输延迟不可避免。 ，就注定它不是低延迟直播的最佳解决方案。 直播延迟排查思路 如果想从本质上解决直播延时问题，还是要换成基于 UDP 的私有协议来传输数据。 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 - 来自专栏音视频技术
基于强化学习的低延迟视频传输，虎牙自研传输网络架构实践，面向流媒体的确定时延传输
基于强化学习的低延迟视频传输 Topic 《强化学习驱动的低延迟视频传输》 周安福 北京邮电大学 教授，博士生导师 随着视频会议、视频直播的流行以及未来AR/VR业务的发展，低延迟视频传输服务被广泛使用 进一步地，我们设计了基于在线强化学习的视频传输系统，并在产业届大规模部署应用。 1. 实时视频传输背景 2. 为什么基于规则的算法导致低QoE 3. 而且在音视频传输上，虎牙直播一直保持有一套相比CDN有明显差异化能力的网络。 本次将首次对外分享虎牙在自建传输网络上的架构以及经验。 一切围绕降成本，探索自建网络最低成本可能方案 面向流媒体的确定时延传输 Topic 《面向流媒体的确定时延传输：从 QUIC 出发，走向未来》 马川 清华大学 研究生 QUIC 协议是谷歌公司开发的全新传输层协议 Media over QUIC 工作组介绍与未来展望 所属专题 相关阅读推荐 万人场景下传输挑战和演进实践 OWT基于TCP以及QUIC的级联方案 华为云SparkRTC面向低时延、大通量传输业务的技术探索
1.5K20编辑于 2023-02-24
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号