上述播放器所用的传输协议很有趣,除了苹果播放器之外,其他都用的是 DASH 协议: Native AVPlayer - HLS; ExoPlayer - DASH; Roku Player - DASH 和 dash; Roku - 不支持,只能使用 roku 之前的单个编解码器播放列表 h265,支持 dash/hls 的其中一种,或 h264,支持 dash/hls 的某一种协议播放(截至 2020 和 Dash; dash 播放器和hls 播放器都加密一次(加密方法); 所有设备可以解密所有媒体格式。 如果您需要支持 CENC,则需要为 hls 和 dash 提供 2 套媒体格式。 这样做的问题在于,特定的 DASH 播放器可能无法在两个视频编解码器之间切换。 实际产品中 80% 的播放错误与 DRM 以及 hls/dash 的封装有关。
本文来自The broadcast knowledge的演讲,演讲者是FuboTV公司的工程负责人Nick Krzemienski,演讲内容为HLS和DASH多编解码器的编码和打包。 现在众多播放器中,仅有非常少数接受的是HLS,绝大部分皆为DASH。 从理想情况开始,即将单个fmp4同时编码为h264与h265的情况开始,他将二者都打包为HLS和DASH,然后让播放器去选择其支持的内容。 而在两种编码器不在一个播放器下同时可用时,就需要先将fmp4转码为 h264与h265输出文件,再先后将其打包为HLS与DASH。 这可以保证在打包之前进行一个DRM流程,但是实际上如果要使用CENC,则需要两套HLS与DASH媒体,且可能特定的DASH播放器无法在两个视频编解码器之间切换。
网络电视(IPTV): 虽然IPTV通常使用其他协议(如HLS、MPEG-DASH等)进行流媒体传输,但在某些情况下,RTMP也被用于IPTV服务中,特别是在需要低延迟传输的场景中。 无论是直播、点播还是其他形式的流媒体服务,这些协议都扮演着关键角色。 2. 适应多种网络环境 网络适应性:这些协议都设计有在网络条件变化时保持传输稳定性和连续性的机制。 例如,HLS和DASH通过将媒体内容切分为多个小片段,并根据网络状况动态调整传输的码率和质量,以适应不同的网络环境。 3. RTMP、RTSP、RTP、HLS、DASH这些协议在服务于流媒体传输方面有着共同的目标和追求,同时也在各自擅长的领域发挥着重要作用。 好多客户或开发者跟我们交流的时候,会问我们,为什么不支持HLS、DASH、Smooth Streaming等,其实只要还是核心能力侧重的问题,大牛直播SDK始于2015年,致力于传统行业极致体验的音视频直播技术解决方案
另外 hls.js 对于 fmp4 还是测试阶段,可以使用更通用的 ts 格式取代。 DASH 基于HTTP的动态自适应流(Dynamic Adaptive Streaming over HTTP,缩写DASH,也称MPEG-DASH)是一种自适应比特率流技术,使高质量流媒体可以通过传统的 DASH 和 HLS 非常相似都是使用 manifest 描述视频信息和播放列表,然后通过 HTTP 自适应的请求合适的片段。 与 HLS 不同的是 DASH 是 国际标准,而 HLS 属于苹果公司。 字段 描述 Period 代表一个场景或一段歌曲,表示某一个时间段,可以在这里穿插广告 AdaptationSet 描述媒体流的信息,比如是音频流还是视频流 Representation 用来表示不同屏幕大小或码率 但因为 HLS 出现的更早,更简单,有苹果公司支持等原因,现在比 DASH 更加常用,而且它们都基于 MSE,而 MSE 不支持 IE 10及以下。
Tim Siglin: 你们的服务更看重服务视频质量、延迟,还是什么? Scott Grizzle: 我们认为最重要的是最高质量的视频流,并保证其稳定性。实际上,我们使用多个CDN进行传送。 所以,大多数编码器亦是如此,这就意味着大多数的用户将使用RTMP或HLS或其他格式。 Tim Siglin: 最后一个问题是关于DASH与HLS。在传输方面要求使用DASH 和HLS,你有什么看法? 现在你在HLS和DASH上也看到了相似之处。现在的DASH不像其他的那么极端,编码端更重一点,解码器更轻。但是你现在在DASH上看到了的交付时间更快。而且,它们不具有与HLS相同的分块或块。 另外,如果你关注DASH,你会注意到有更多的公司参与DASH。 再次,这有点像回到H.264和VC1。拥有更多的人贡献。它需要花费比微软和苹果这样的HLS更长的时间去推进,但它们可以快速完成任务。 你认为苹果公司会通过找出HLS方面的一些事情来回应DASH的交付优势,又或者你认为它们是否本质上必须重构整个包装解决方案?
本文是来自MHV(Mile High Video)2019的演讲,演讲的作者是来自Tencent America的Iraj Sodagar,同时Iraj也是MPEG DASH小组主席、DASH-IF主席 本次演讲主要展示 了未来将要发布的MPEG DASH第四版新增的功能。 在演讲的开始,Iraj简要介绍了MPED DASH第三版的内容,随后着重介绍了今年年底或明年年初将要发布的MPEG DASH第四版的一些新的功能,有服务描述(延迟、操作质量、操作带宽);初始化集、组和表示 随后介绍了DASD-IF(DASH Industry Forum)当前的工作计划,包括DASH-IF实时媒体摄取规范、低延迟DASH指南、事件和定时元数据处理API、广告插入通用架构。 最后讨论了当前DASH的限制和挑战。 演讲PPT全文 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
许多播放器支持 LL-HLS 和/或 LL-DASH 协议,包括 Apple 的 AVPlayer、Shaka 播放器、HLS.js Dash.js 等。本文致力于分析低延迟播放器和流媒体协议的性能。 这些结果随后用于描述观察到的 LL-HLS 和基于 LL-DASH 的播放器的性能差异。 实验设置 流媒体工具链 我们用于 LL-HLS 和 LL-DASH 流的工具链的总体图分别如图 1 和图 2 所示。 LL-HLS 流由 NGINX 网络服务器动态提供。LL-DASH 流由 node-gpac-dash 动态提供。 接下来,输出流文件由低延迟媒体服务器(用于 LL-HLS 的 lowLatencyHLS.php,用于 LL-DASH 的 node-gpac-dash)以分块的方式提供给播放器。
它们可以被配置为单码率视频流(普通mp4文件)、HLS、MPEG-DASH、HDS等。 除此之外,它同样支持DASH、HLS、边下载边播放和广告插入、动态Overlay、画中画等功能。 THEOplayer的HTML5视频播放器支持HLS、DASH、Smooth Streaming以及HLS和DASH的低延迟变体协议。 Flowplayer支持HLS、DASH和mp4播放。 作为跨设备的HTML5视频和音频播放器,它能够显示HLS、DASH或progressive(边下载边播放)下载内容。
Vivado HLS 2020.1将是Vivado HLS的最后一个版本,取而代之的是VitisHLS。那么两者之间有什么区别呢? 例如,在Vivado HLS下,默认是不会对循环设置Pipeline的,但在Vitis HLS下,只要循环边界小于64,就会对循环设置Pipeline。 在Vivado HLS下,默认Clock Uncertainty是时钟周期的12.5%,但在Vitis HLS下更严格,达到了27%。 ? 对循环而言,在Vivado HLS下,II(Initial Interval)默认的约束值为1,但在Vitis HLS下,II默认值为auto,意味着工具会尽可能达到最好的II。 User Guide Vitis HLS examples: https://github.com/Xilinx/HLS-Tiny-Tutorials
HLS和DASH是两大基于HTTP的流媒体通信协议。随着人们对低延迟需求的不断提高,这两个协议都发展出了各自的多个低延迟版本。 在Mile High Video 2019(MHV/2019)上,来自Akamai的Will Law做了题为“LL-HLS LHLS DASH-LL, Challenges and differences 首先,本次演讲中的LL-HLS是指苹果公司在WWDC2019上发布的低延迟HLS协议,LHLS是指由JW、Mux、Wowza等公司牵头开发的社区版低延迟HLS,DASH-LL是指低延迟DASH协议。 LHLS和DASH-LL都是使用分块传输编码(CTE),即一个视频可以分为多个部分发送给客户端,且客户端只需请求一次,而LL-HLS没有使用,即如果视频分为多段发送,客户端需要依次请求各个部分。 另外,相较于LHLS和DASH-LL,LL-HLS客户端的请求速率将大幅增加,且LL-HLS还需要HTTP2支持,但这一特性使得其可以配合CDN降低用户请求数据时与源服务器之间的通信延迟,从而进一步降低端到端延迟
有WebRTC/MPEG-DASH和HLS等。 MPEG-DASH 技术由 MPEG 主导开发: 2010年开始DASH相关工作, 2011年1月成为国际标准草案, 2011年11月成为国际标准, 2012年4月,MPEG-DASH 以ISO/IEC HLS/HDS/MSS 苹果 Adobe 微软 各自实现的一套基于HTTP的自适应串流。HLS应用相对会广泛一些。 这里有一篇文章对MPEG-DASH/HLS/HDS/MSS进行了对比 MPEG-DASH vs. Apple HLS vs. Microsoft Smooth Streaming vs. / 可用的JS框架 https://github.com/Dash-Industry-Forum/dash.js/
有WebRTC/MPEG-DASH和HLS等。 MPEG-DASH 技术由 MPEG 主导开发: 2010年开始DASH相关工作, 2011年1月成为国际标准草案, 2011年11月成为国际标准, 2012年4月,MPEG-DASH 以ISO/IEC HLS/HDS/MSS 苹果 Adobe 微软 各自实现的一套基于HTTP的自适应串流。HLS应用相对会广泛一些。 这里有一篇文章对MPEG-DASH/HLS/HDS/MSS进行了对比 MPEG-DASH vs. Apple HLS vs. Microsoft Smooth Streaming vs. / 可用的JS框架 https://github.com/Dash-Industry-Forum/dash.js/
有WebRTC/MPEG-DASH和HLS等。 MPEG-DASH 技术由 MPEG 主导开发: 2010年开始DASH相关工作, 2011年1月成为国际标准草案, 2011年11月成为国际标准, 2012年4月,MPEG-DASH 以ISO/IEC HLS/HDS/MSS 苹果 Adobe 微软 各自实现的一套基于HTTP的自适应串流。HLS应用相对会广泛一些。 这里有一篇文章对MPEG-DASH/HLS/HDS/MSS进行了对比 MPEG-DASH vs. Apple HLS vs. Microsoft Smooth Streaming vs. / 可用的JS框架 https://github.com/Dash-Industry-Forum/dash.js/
由Apple和Microsoft合作,CMAF的想法是为HLS或DASH(两种主流流媒体协议)创建标准化的传输容器,以避免视频流工作流程中增加的成本与复杂性。 Alexander表示,大约三到四年前,无论是使用HLS还是DASH,端到端延迟的默认值大约为30~45秒。 Luther说,与许多人希望的相比, CMAF需要更长的时间来获得行业认可采用,他说DASH也是如此。 另外,他谈到HLS是当今流媒体的主流格式,而具有MPEG-2传输段的HLS可以很好地满足当今大多数流媒体的需求。 块转移的未来 2016年,当苹果宣布向HLS添加fMP4支持时,CMAF块运输得到了很大的推动。我们的想法是,CMAF将减少为编码为HLS和DASH的内容设置单独的筒仓的需要。
缩写: HLS:HTTP Live Streaming ABR:Adaptive Bit Rate DASH:Dynamic Adaptive Streaming over HTTP 查找HLS的切片格式的时候发现有 HLS只支持MPEG-2 TS。DASH媒体段通常比HLS短,2至4秒比较常见。DASH不需要特定的编解码器。视频可以使用H264编码,也可以用其他编码,VP9和H265也是比较受欢迎的编码。 一般而言,与HLS相比,DASH可以提供实质上更低的端对端延迟。这对于现场直播的工作流程很重要。 此外, MPEG-DASH的基于模板的MPD不需要更新,可以在网络边缘服务器进行缓存,HLS则需要周期性地更新传播多次。 DASH中的重要概念 MPD :媒体文件的描述文件(manifest),作用类似HLS的m3u8文件。MPD文件以XML格式组织,其层次结构参图1。
支持播放格式:MP4、HLS、FLV、MPEG-DASH 兼容性: PC Web端支持直接播放mp4视频,播放HLS、FLV、MPEG-DASH需要浏览器支持Media Source Extensions iOS系统Web场景支持直接播放mp4和HLS,不支持播放FLV、MPEG-DASH 安卓系统Web场景支持直接播放mp4和HLS,播放FLV、MPEG-DASH需要浏览器支持Media Source 支持格式:HLS,FLV,MPEG DASH,WebTorrent
CTA-WAVE 最近发布了 DASH-HLS 互操作性规范,该规范描述了 DASH 和 HLS 应如何利用 CMAF 内容,并对 DASH 和 HLS 清单文件之间的映射进行了规范。 与 LL-DASH 播放器不同,苹果 LL-HLS 播放器并不利用 CMAF 片段,因为这些平台上的启发式传输依赖于全线速传输,但至少它们与之兼容,这使得 LL-HLS 和 LL-DASH 清单文件之间共享一套媒体片段成为可能 LL-)DASH 在所有的 iOS 浏览器中挑战 (LL-)HLS,并将 HLS 的相关性只限制在编译的应用程序的范围。 DASH 清单文件优化 目前有几项正在进行的计划,以减少 DASH 清单文件的大小——还没有与 HLS 清单一起。 它基本上是将单播的 DASH 或 HLS 流作为输入,并将其转化为多播的 DASH 或 HLS 的直播边缘片段,视频播放器以单播方式请求 DVR 片段,传递直播内容的最后几分钟。
最近几年,在线视频行业发展十分迅速,无论是视频播放设备还是视频传输技术都在不断革新,从60英寸的UHD平面屏幕到平板电脑或者手机,从光纤网络到3G,4G的蜂窝网络技术,这些技术的革新使得流媒体视频制作人员要支持多种自适应流技术 第二个方面技术是Common Media Application Format(CMAF),是一种文件格式规范,可以打包支持多种自适应流技术,包括HLS和DASH。 因为HLS使用MPEG2传输流容器,而DASH和其他HTTP技术使用Fragmented MP4文件,如果视频发布者想要访问所有设备,它必须打包并提供每个视频的两个版本 - 一个是HLS,一个是DASH 直到2016年苹果和微软合作并宣布了DASH和HLS的通用格式之前,一直是需要提供两种版本才能访问所有设备。我们将在后面介绍这个通用格式。 如图7所示,具有HLS和DASH的manifest的单个CMAF文件集和CBC加密可以使用FairPlay for HLS和Widevine for DASH来支持所需的设备。 ?
问题1:公司是否继续使用HLS和DASH,如果是预计会持续多久。 Cyril:Neflix不是严格意义上使用HLS和DASH,因为没有使用清单格式。 我认为HLS和DASH不会很快消失,因为CMAF规范无法解决cbcs和ctr的争论。 Nick:我们仍然在本地HLS客户端使用MPEG-TS和F-MP4的组合。 Bill:Disney Plus已经全部采用HLS CMAF,但是仍需在很小一部分设备上用DASH打包。 Peter:我们预期在较长时间里用HLS和DASH来存储和交付。 目前在DASH、HLS和CMAF上都使用H264和HEVC的组合,并且将继续参与AV1和VVC的未来工作。 Jan:从播放器的视角来说,设备通常采用DASH或者HLS播放,CMAF是同时包含DASH和HLS清单文件信息的包装格式。因此你可以同时为支持HLS和DASH的设备创建一个可以播放的文件集。
然后就是一些现在看来很常见的问题,比如说卡顿,慢启动等等问题,但是在 2016 年处理起来还是很困难,因为在之前没有任何人进行这方面的研究。 到了 2017 年,低延时得到了更多的关注。 2018 年的时候,低延时 dash 正式发布。与此同时,也有一些会议提到了之后是否会有低延时 HLS 的出现。但所有这些都发生在整个 WWDC 故事之前。 这样每个块之间都有阻塞时间,这在低延时 dash 中也是一个很难解决的问题。 图1 在实现低延迟 HLS 之前,我们已经解决过低延时 dash 的很多问题。 低延时 dash 在网络状况突然崩溃的情况下表现得并不好,响应很慢,而且对带宽估计并不准确。于是我们考虑是不是能在低延时 HLS 中做的更好。 除此之外,即使你知道了从哪一个部分可以正确启动,但是在 dash 中你仍然没有一个正确的时间参考。然而,在 HLS 中就不需要考虑时间参考的问题。 总体的流程如如图 4 所示。