在本系列上一篇文章《定义和测量延迟》中,介绍了为什么延迟是OTT传输的一个问题以及如何测量端到端延迟中不同传输步骤所占的延迟比重。 本文接下来介绍可能的延迟优化,从编码,打包,CDN交付以及视频播放器这些过程,通过调整其中的参数,可以为观众提供一个经过精心优化的低延迟直播流。
近些年直播行业可谓是越来越火,英雄联盟的赛事直播、罗老师的直播带货、电商平台的购物节这些动辄就是几千万的流量,都是大家可以在日常生活中接触到的。可是无论哪种类型的直播,延时是直播过程中需要重点关注的一个点。直播实现低延迟,是对大部分直播产品的要求,也是提升直播产品用户体验最有效的一个方法。特别是体育赛事、直播互动、在线答题等场景对低延迟要求更高。今天简单跟大家介绍下如何直播如何实现低延迟。
本文来自BITMOVIN,由Jameson Steiner编辑,是实时低延迟流媒体系列的最后一部分。
新知系列课程第二季来啦!去年的系列课,我们为大家介绍了直播、RTC、IM、媒体处理等音视频通信技术,这一次,我们将继续为大家带来全真互联时代下新的行业趋势、新的技术方向以及新的应用场景分享。今天,我们邀请到了腾讯云音视频技术导师——付秋平,他将结合实际案例,为大家介绍流媒体源流中常见的问题,以及延迟分析处理的方法。 今天的内容分为播放器播放流程、直播源流常见问题、直播延迟的产生与处理、WebRTC快直播四个部分。 播放器的播放流程,基本上是推流的逆向过程。推流端基于同一个时钟源进行音频和视频的采集,得
在未知或不断变化的网络条件下的操作一直是自适应比特率流媒体系统自 1990 年代诞生以来一直试图解决的最基本挑战之一。这个挑战今天仍然存在,尽管在某种程度上简化了设置,允许使用基于 HTTP 的自适应流 (HAS) 架构。在这样的架构中,网络适配逻辑驻留在流媒体客户端中,有效地驱动媒体流片段的选择和加载。在过去的十年中,已经提出了许多先进的方法来设计流选择算法。这包括基于吞吐量的方法、基于缓冲区级别的启发式、控制理论方法以及机器学习算法。
苹果公司的低延迟 HLS (LL HLS)的承诺是比标准 HLS 更低的延迟,并向后兼容非 LL HLS 的播放器。Mux 视频服务的承诺是“视频,在几秒钟内”。正如你将在本教程中所看到的,两家公司都达到了他们的目标,Mux 的 LL HLS 特别容易实现,延迟为 4-7 秒,比预期的要高一点,但与其他提供相同服务的公司一致。
想要优化延迟,可Latency到底是多少?延迟始终是媒体内容传输的一个重要关注点,人们也在不断尝试用新的方法来优化延迟,本文参考AWS的一些新技术,介绍了延迟的定义,以及如何具体测量延迟,给出了延迟的量化概念。
今天我们将谈论最近的一个低延迟直播的作品。一个有趣的事实是,在 1969 年,一个来自月球表面的直播被数亿人观看,他们的延迟大约是 3 秒,50 年后,超级碗也有数百万的流媒体播放,但在这种情况下延迟超过 45 秒。然而,在过去几年中,低延迟在实施和标准化方面取得了很多进展,因此我们的处境要比几年前好得多。低延迟的主要驱动因素之一就是现场体育赛事。
使用在线流媒体平台做直播时,实时体验至关重要:看世界杯时,您还边正在聚精会神地盯着C罗的金刚腿等着罚球,隔壁老王就传出进球欢呼声,您肯定无比郁闷。视频播放领域的新锐——THEOplayer,不久前写了三个不错的系列文章,详细分析了造成视频传输延迟的原因,介绍了两个缩小延迟的解决方案:CMAF和LHLS,为提升直播观看体验提供了思路。话不多说,各位热爱媒体技术的小伙伴们,Let’s Go~
好多开发者提到,在目前开源播放器如此泛滥的情况下,为什么还需要做自研框架的RTMP播放器,自研和开源播放器,到底好在哪些方面?以下大概聊聊我们的一点经验,感兴趣的,可以关注 github:
本文来自THEO网站的博客文章,原标题为LL-HLS Series: The Evloution of LL-HLS。主要内容为讨论低延迟HLS系列。
N(>=3)年前Adobe官宣了2020年底就不支持Flash了,最近发现非常多的朋友,到了真正完全不能用时,才考虑如何逃生,一顿狂问“没有Flash了怎么播放RTMP”,“该选HTTP-FLV还是WebRTC”,“用什么播放器播HTTP-FLV”。
本文来自THEO的行业研讨会,演讲者是THEO的CTO和创始人Pieter-Jan Speelmans。本文的主题是苹果最新推出的LL-HLS。
本文来自BITMOVIN,由Jameson Steiner编辑,文章主要内容是“实时低延迟流式传输”。
判断一套一对一直播源码好不好用,质量达不达标,用户体验如何,无非就是从延迟状况、成功播放率、首屏耗时和画面的质量清晰度这四个方面进行评判。接下来小编将一一讲解。
好多开发者提到,在目前开源播放器如此泛滥的情况下,为什么还需要做自研框架的RTSP播放器,自研和开源播放器,到底好在哪些方面?以下大概聊聊我们的一点经验,感兴趣的,可以关注 github:
直播系统开发是一个复杂的工程系统,要做到非常低延迟的直播,需要复杂的系统工程优化和对各组件非常熟悉的掌握。这里面我们再分享几个简单而常用的调优技巧。
在过去的15年中,直播行业得到了巨大的发展。最初的流媒体传输模仿了广播传输的工作流程,使用自定义服务器通过专有协议提供流服务。在HTTP自适应流媒体(HTTP Adaptive Streaming,HAS)发展的推动下,直播行业的发展使观众对OTT质量和延迟有了更高的需求。传统观点认为,HAS传送的内容具有端到端延迟,该延迟是切片(segment)时间的几倍,并且这种延迟比广播中的延迟更久。有一种HAS解决方案能够实现低于一个segment时间的端到端延迟,它甚至使得整个延迟与segment的持续时间无关,即超低延迟CMAF(ULL-CMAF)。
有些人呐,真是不见棺材不落泪,N(>=3)年前Adobe官宣了2020年底就不支持Flash了,最近发现非常多的朋友,到了真正完全不能用时,才考虑如何逃生,在群里一顿狂问“没有Flash了怎么播放RTMP”,“该选HTTP-FLV还是WebRTC”,“用什么播放器播HTTP-FLV”。 本文只发一次,完整解决方案再啰嗦一遍,恕我不在群里回答这种问题了,自己花时间好好看吧,身为搞直播的研发工程师,总不能火烧了眉毛才开始想办法吧,各位耗子尾汁吧。 看完视频,请看详细方案。 没有Flash了怎么做直播? 答
https://mux.com/blog/the-community-gave-us-low-latency-live-streaming-then-apple-took-it-away/
在WWDC 2019上,Apple 依照惯例宣布了一系列的软件更新。并且像过去4年的传统一样,Roger Pantos上台宣布了HTTP直播视频流(HLS)规范的最新变化,今年的变化旨在减少实时视频流的延迟,但这样做的代价是什么呢?
好多开发者在做产品竞品分析的时候,不知道如何界定一个RTSP播放器,大牛直播SDK认为,一个RTSP播放器,不是说有几个类似于Open/Close接口就够了,好的RTSP播放器需要具备以下功能和性能属性:
导语 | 快直播是对标准直播边缘进行WebRTC改造的一种低延迟直播产品方案,在低延迟的同时,完全兼容标准直播的推流、云端媒体处理能力,并具有CDN强大的分发能力。客户可以从现有的标准直播平滑地迁移到快直播上来,快速实现低迟时直播场景应用[1][2]。快直播接入方式主要有两种:第一种通过浏览器和H5接入标准WebRTC,第二种通过SDK接入升级扩展的WebRTC。一般WebRTC SDK包含全套拉流、解码、渲染等功能,而在传统标准直播的客户中,往往已经有一套播放器和相应的业务逻辑,如何基于现有播放器快
点击上方“LiveVideoStack”关注我们 ▲扫描图中二维码或点击阅读原文▲ 了解音视频技术大会更多信息 // 编者按:作为一个历经了21个年头的播放器,VLC旺盛的生命力使其在今天仍然有着一席之地。但是21年前的定位所带来的与当今主流媒体播放器的差距依然不可小觑。LiveVideoStackCon2022上海站大会我们邀请到了腾讯云 客户端开发工程师 赵志立,为我们分享他们是如何让VLC走进低延迟的大门的以及VLC的未来是怎样的。 文/赵志立 整理/LiveVideoStack 大家好,
随着互联网基础设施的完善以及4G、5G等技术的大规模商用,在Chrome、Firefox、Edge等浏览器播放RTSP视频流也慢慢成为了信息化系统的行业标准。
虚拟现实(VR)技术的互动性和沉浸感,为我们提供了一种全新的视觉体验,不过,如果需要实现真正的沉浸式体验,VR播放的延迟问题非常重要。
原文:https://www.fiercevideo.com/tech/cmaf-coming-and-it-could-dramatically-improve-livestreaming
近期在做摄像头监控视频在网页中播放的工作,现在大部分摄像头厂商如海康威视、大华、华为等都支持标准的RTSP协议,RTSP协议的优势是实时性高、流畅度度高,同时支持H.265和H.264,清晰度也更高,对于要求比较高的安防、交通等领域很适合,交通行业特殊需要延迟低于300毫秒,于是开始收集各种方案,互联网上RTSP协议的网页播放方案也很多,但是基本上分为两种:
动手点关注 干货不迷路 世界杯已经结束了,梅西带领阿根廷时隔三十六年之后终于如愿捧杯。抖音直播提供的 4K 超高清超低延迟看播能力给亿万观众留下了深刻的印象,决赛的 PCU 达到 3700w+,在这样大规模并发下,如何能稳定流畅地做到更低的延迟,是一个巨大的挑战。本文主要介绍世界杯期间火山引擎视频云和相关团队在低延迟上的工作和优化,作为低延迟方向上的总结。 本文主要讨论生产和传输环节的延迟。生产环节的延迟主要受视频流供应商控制,技术团队可以实现的是,尽可能准确地测量出生产的每一个环节的实际延迟,并在发现
试用猿大师播放器播放一路视频效果很不错,延迟可以控制在200毫秒左右,但是如果播放多路高清视频,CPU占用就会比较高,并且网页也会卡顿,该如何解决呢?
如果你问一个前端技术人员,近几年最火的前端框架技术是什么,肯定会有人说VUE,确实VUE凭借其简单特性赢得了大家的喜爱,而近期公司有个项目,需要在VUE框架网页上播放RTSP实时视频。
七牛云于6月底发布了一个针对视频直播的实时流网络LiveNet和完整的直播云解决方案,很多开发者对这个网络和解决方案的细节和使用场景非常感兴趣。
// 编者按:赛事直播场景与普通直播场景有一定差异,赛事直播场景对码率、画质、延时等性能要求更高。LiveVideoStackCon 2022 音视频技术大会上海站邀请到了腾讯专家工程师,媒体直播负责人——吴昊老师,为我们分享《腾讯视频云流媒体技术探索——赛事直播场景的技术优化》,他将介绍如何利用多路径传输、QoS控制,以及跨区调度和加速的能力,优化端到端的传输质量。在媒体处理和封装上,他将介绍通过多码率自适应、低延迟、多音轨、广告插入等技术,提升终端的播放体验,同时满足国内及海外不同场景的需求。
SkeyeVSS视频云支持HEVC/H265编码格式的摄像机直接接入,同时不需要后台转码,直接在WEB网页前端采用H5直接进行无插件播放;
随着网络宽带的不断提升和智能手机的流行,RTSP实时视频流播放及处理不再局限于安防行业。在如道路、工厂、楼宇、学校、港口、农场、景区等诸多场景实施的信息化系统中,绝大多数都采用的是B/S架构,隐藏迫切需要在浏览器中嵌入多路摄像头RTSP流低延迟(小于500毫秒)播放功能,而在IE及Chrome 45以下版本等浏览器中,采用ActiveX控件或NPAPI插件即可实现。然而美好总是短暂的,从2015年开始Chrome及Firefox等浏览器纷纷取消了NPAPI插件的支持,而IE又在与Chrome
2015年之前还可以用VLC原生播放器在Chrome、Firefox等浏览器中直接播放,延迟比较低,效果也还不错。可惜好景不长,从 2015年Chrome、Firefox等浏览器取消了对 NPAPI插件的支持,海康威视官方提供的 web3.0开发包也只能在低版本浏览器播放。
这几年,我们对接了太多有RTSP或RTMP直播播放器诉求的开发者,他们当中除了寻求完整的解决方案的,还有些是技术探讨,希望能借鉴我们播放端的开发思路或功能特性,完善自己的产品。
现在到处是摄像头的时代,随着带宽的不断提速和智能手机的普及催生出火热的网络直播行业,新冠病毒的大流行又使网络视频会议系统成为商务会议的必然选择,因此RTSP实时视频流播放及处理不再局限于安防行业。在如道路、工厂、楼宇、学校、港口、农场、景区等场景实施的信息化系统中,已基本全采用B/S架构,迫切需要在浏览器中嵌入多路摄像头RTSP流的超低延迟(小于500毫秒)播放功能,而在IE及Chrome 49以下版本等浏览器中,采用ActiveX控件或NPAPI插件即可实现。然而美好总是短暂的,从2015年开始Chrome及Firefox等浏览器纷纷取消了NPAPI插件的支持,而IE又在与Chrome及Firefox等浏览器竞争的过程中不断被用户抛弃,到现在市场份额已降到可怜的个位数。微软在几经折腾后,索性也拥抱Chromium内核推出Edge新版来杀死自己的IE,以挽救自己在浏览器这块岌岌可危的江湖地位。
试想一下,当你和朋友进行视频聊天时,这时突然画面卡住不动了,而且声音变得断断续续,是不是会感到特别的尴尬?为了避免这些情况,那么在视频交友app开发过程中,针对于延迟,在技术上能对哪些方面进行优化呢?下面就来简单介绍下。
HLS.js 是一款由苹果公司开发的,在浏览器中播放 HLS 的视频播放器。在最近,苹果发布了 Safari 浏览器中的低延时 HLS(LL-HLS),同时在其他浏览器中实现了基于 HLS.js 的播放器。
点击上方“LiveVideoStack”关注我们 作者:Anthony Dantard 翻译:Alex 技术审校:袁荣喜 ▲扫描图中二维码或点击阅读原文▲ 了解音视频技术大会更多信息 ---- 低延迟协议 影音探索 #013# 用户对服务的期望在不断攀升,并逐渐出现了不满情绪。由于有了YouTube和Netflix这样的视频服务,我们都希望在观看点播视频时获得超快的下载时间和流畅的播放体验。可能不太明显的是,无论我们是否意识到,这种期望都正在慢慢地向实时音频通信和直播应用转移。 在api.vid
随着移动设备大规模的普及以及流量的资费越来越便宜, 超低延迟的场景越来越多. 从去年到今年火过的场景就有在线娃娃机, 直播答题, 在线K歌等. 但要做到音视频的超低延迟确是很不容易, 编码延迟, 网络丢包, 网络抖动, 多节点relay,视频分段传输,播放端缓存等等都会带来延迟.
玩法开天辟地,体验不留缝隙。K歌不遗余力,应用解决效益。总是羡慕别人家的“歌房”苦叹自家“茅草房”消除不了回音和混音?这次就将带你实战K歌功能,细分应用场景,提升产品表现,为你在“造房“路上“添砖加瓦“,给你最实用的”武器“,让你的”K歌房“摆脱尴尬的余音绕梁,从此高品质翱翔。看淡K歌之王,用技术推你做”K歌王中王“!
概述 2016年基本上可以说一个直播年,各大互联网挣相进入直播行业,成就了直播技术的发展。之前我们也对直播连麦技术做了一个简单的分析,但是没有从整体上介绍,今天我们就组一个整体的介绍(本文部分资料来源于网络)。 我们先来看看视频直播的5个关键的流程:录制->编码->网络传输->解码->播放。每个环节对于直播的延迟都会产生不同程度的影响,这里重点分析移动设备的情况。针对移动场景总结出直播延迟优化的4个点:网络、协议、编解码、移动终端,达到UCloud直播云实现低延迟、秒开的技术细节。 直播技术分析 UCl
在上一篇文章讲了音视频一些疑难问题的排查,其中一个比较重要的原则就是要将音视频作为一个系统来看待,问题有可能只是表现在播放端,但是根因有可能在编码端,也有可能发生在传输过程中。其实对于音视频有些问题的优化,有时也要整体优化,比如延时这种问题。
原标题:Using LL-HLS with Byte-range Addressing to Achieve Interoperability in Low Latency Streaming
当我们玩游戏时,我们可能会听到声效,但是不会真正注意它们。因为希望听到他们,所以声效在游戏中是非常重要的。
原文地址:Understanding Audio Focus (Part 2 / 3): More Audio Focus use cases 原文作者:Nazmul Idris (Naz) 译文出自
本次网络研讨会探讨了关于DVB-I规范为线性电视服务提供的以Internet为中心的解决方案。尽管DVB-I服务列表可以参考通过宽带和/或广播提供的服务,但该规范的主要开发目的是为宽带观众带来传统数字电视的用户友好性和鲁棒性。该网络研讨会考虑了线性电视内容的宽带传输的关键技术。演讲者分别是来自华为的业务和技术开发Paul Higgs,他是DVB TM-I组的主席,以及来自Unified Streaming的研究和标准化主管Rufael Mekuria,他是DVB TM-STREAM组的主席
领取专属 10元无门槛券
手把手带您无忧上云