写点什么

第四部分:如何借助当前的自适应比特率技术降低广播延迟

2019 年 10 月 08 日

第四部分:如何借助当前的自适应比特率技术降低广播延迟

第四部分:参考架构和测试结果

在本系列博文的前几篇文章中,我们探讨了通过视频处理、分发链和视频播放器优化延迟的方法。接下来,我们来研究一些参考架构,这些架构能够在优先考虑低延迟的视频直播工作流部署,以及端到端延迟方面带来最好的相关结果。我们从两个方向开展研究,所用的场景为:一个可以完全在本地部署的场景、三个包括在现场编码或提供支持的混合场景,以及使用云端的 AWS Elemental Media Services 的其余工作流程。我们相信通过这种方式,您能够直观地展示您对现有设备和服务的期望,同时帮助您了解如何将它们与 AWS Elemental Media Services 结合使用,来实现符合您要求的延迟等级。


这些测试中使用的常见参数是编码配置文件和 DASH 打包参数:


  • 编码:AVC 360p@700Kbps/720p@3Mbps/1080p@5Mbps

  • DASH 打包:

  • SegmentTemplate/

  • minBufferTime=“PT2S”

  • suggestedPresentationDelay=“PT1S”

  • timeShiftBufferDepth=“PT3S”

  • 在表格中,您可以看到用于测试流的不同变体:

  • 3x1s:表示 DVR 播放列表显示 3 个 分段,每个分段 1 秒钟

  • 3x2s:表示显示 3 个分段,每个分段 2 秒钟

  • 3600x1s:表示 DVR 时长为 1 小时,分段时长 1 秒钟

  • 我们的目标是找出产生短分段的最有效策略,以及标准播放器和优化的播放器在较长的播放时长内(如 45 分钟)的表现。HEVC 和 fMP4/CMAF 作为对传统 HLS 和 DASH 与 AVC 的补充,还需要经过更多测试。尽管如此,当前测试结果仍然能够很好地概述借助 AWS Elemental 解决方案和各种播放器可以实现的延迟水平。


我们先来看一个完全在本地部署的场景。在该场景中,我们使用 AWS Elemental Live 来编码,使用 AWS Elemental Delta 来打包和生成。就相当于一个用于多屏分发的典型付费电视运营商工作流程,全部设备都部署在本地。


场景 1



该场景经过了几种类型的摄取格式测试:HLS 和 RTMP 的输入结果比 UDP 略好一些。在绿色单元格中,我们列出了能够带来最佳播放稳定性结果的组合。虽然在 AWS Elemental Delta 上可以生成 1 秒分段,但是与之配合使用的存储解决方案的读/写性能将限制生成和分发该 1 秒分段的速度,从而以可接受的重新缓冲大小播放。使用移动版 Safari 和 2 秒分段进行测试的结果比 10 秒的阈值略高,这显然难以令人满意。


播放器3x1s HLS3x2s HLS3x1s DASH3x2s DASH
hls.js 0.8.76.86 秒8.44 秒--------
dash.js 2.6.5--------5.94 秒8.23 秒
移动版 Safari (iOS 11.2.2)6.04 秒11.65 秒--------
Exoplayer 2.6.0 (Android 6.0.1)6.14 秒10.19 秒5.49 秒7.14 秒


使用 AWS Elemental Delta 和常规存储解决方案,我们的建议是采用 HLS 和 DASH 打包 2 秒分段。使用 1 秒分段需要提供读/写性能更高的存储解决方案。


第二个场景与第一个场景很相似,但是采用了本地和云端的混合工作流程:在本地执行编码,在 AWS 上使用 AWS Elemental MediaPackage 完成打包和生成。这相当于改进现有的现场工作流程,以在大型体育赛事期间等提供临时通道支持。


场景 2


这个场景在延迟方面非常接近第一个场景。在这个测试中,Exoplayer 使用 DASH 时的结果不如其他播放器。总体而言,我们发现此播放器的延迟较难预测。索引时长似乎是造成该结果的关键因素:在所有情况下,采用 DASH 时只显示 3 个分段的结果都各不一样。


播放器3x1s HLS3x2s HLS3x1s DASH3x2s DASH
hls.js 0.8.76.39 秒9.35 秒--------
dash.js 2.6.5--------5.69 秒7.54 秒
移动版 Safari (iOS 11.2.2)6.64 秒10.64 秒--------
Exoplayer 2.6.0 (Android 6.0.1)6.95 秒10.59 秒7.19 秒8.11 秒


使用 AWS Elemental MediaPackage,我们的建议是采用 HLS 和 DASH 生成 2 秒分段,如果使用 1 秒分段,则需要对播放器进行优化。


第三种场景是一种典型的简单直播活动,其中上传带宽在现场是有限的,需要使用支持编码器。比特率变体的编码被分流到基于云端的服务(在我们的示例中是 AWS Elemental MediaLive)上,该服务对直播流进行 HLS 打包,并将其作为源发布到 AWS Elemental MediaStore。


场景 3


下面是我们通过此架构收集的结果。对于 1 秒的分段(使用比特率一半的缓冲区大小参数),延迟略低于 7 秒,这可以很好地满足大多数需求。以下是我们针对特定工作流的分段长度建议。


播放器3x1s HLS3x2s HLS
hls.js 0.8.76.64 秒9.85 秒
移动版 Safari (iOS 11.2.2)6.68 秒12.56
Exoplayer 2.6.0 (Android 6.0.1)8.86 秒11.94 秒


因为 AWS Elemental MediaStore 的设计和性能是专门针对低延迟的,因此除结合 AWS Elemental MediaLive 和 AWS Elemental MediaStore 外,我们还建议使用 HLS 1 秒分段。


上述内容自然而然将我们带入最后一个混合场景。在此场景中,结合使用两种方式,使用 AWS Elemental Live 进行现场编码,在 AWS 上通过 AWS Elemental MediaStore 生成。在此场景中,需要使用多种格式,延迟的可能性最小,并且对上传带宽没有硬性限制。我们只针对此场景测试了 1 秒的分段打包类型,因为这是我们最快的参考架构。


场景 4



与之前的测试相比,我们增加了 Shaka player 2.3.0(标准版)和 Shaka player 2.3.0(优化版)两个新的播放器,以突出播放器优化的优点。我们还将 dash.js 测试播放器升级了到 v2.7.0,因为这个版本带来了全新的低延迟模式(利用 Fetch API),与我们测试中的 v.2.6.5 相比,延迟降低了 0.6 秒(使用 3 秒 DVR)到 4.2 秒(使用 1 小时 DVR)。 在测试期间,我们引入了 AWS Elemental Live 2.12.3 中刚刚推出的一种新格式,即针对 HLS 的 Fragmented MP4 (fMP4),也称为 CMAF,它将传输流 (TS) 分段替换为 MP4 分段。由于这种格式对于 HLS 直播场景而言相对较新,所以研究播放器在使用这种格式时的性能和表现很有趣。这个结果实际上喜忧参半,因为只有一半的播放器在使用该格式。


我们还引入了 1 小时 DVR(3600x1s 列)可用时长,来观察长索引时长时播放器的表现。除了一些异常(如使用 HLS 时的 Shaka),导致延迟接近 10 秒之外,所有播放器的表现都相当不错。


播放器3x1s HLS3600x1s HLS3x1s DASH3600x1s DASH
hls.js 0.8.7(使用 TS)5.32 秒6.30 秒--------
hls.js 0.8.7(使用 fMP4)5.34 秒异常--------
dash.js 2.7.0--------4.90 秒6.50 秒
移动版 Safari (iOS 11.2.2)(使用 TS)5.64 秒5.34 秒--------
移动版 Safari (iOS 11.2.2)(使用 fMP4)7.50 秒9.47 秒--------
Exoplayer 2.6.0 (Android 6.0.1)(使用 TS)5.31 秒7.49 秒6.40 秒7.06 秒
Exoplayer 2.6.0 (Android 6.0.1)(使用 fMP4)6.25 秒7.22 秒6.40 秒7.06 秒
Shaka 2.3.0(使用 TS)异常10.12 秒6.94 秒6.44 秒
Shaka 2.3.0(使用 fMP4)异常9.40 秒6.94 秒6.44 秒
Shaka 2.3.0(优化版)异常6.80 秒 (TS)5.54 秒6.01 秒


使用 fMP4 时,hls.js 会将播放指针定位在开始的 DVR 启动时间,这是导致在 3600x1s HLS 条件下出现异常结果的原因。使用 Shaka 时,3x1s HLS 和解复用音频版本都行不通。1 小时 DVR HLS (TS) 搭配解复用音频的条件下,传输流时断时续。通过对 Shaka 进行以下两种优化,采用 HLS (TS) 和 DASH 时,短 DVR 可用时长的延迟显著降低。


  • config.streaming.bufferingGoal = 2

  • config.streaming.rebufferingGoal = 2

  • 我们目前正在与 hls.js 和 Shaka 开发人员社区合作,以解决在每个播放器中发现的问题。总体而言,结果非常不错,播放器在采用 1 秒分段时的表现均非常稳定。但如此短的分段时长为部分播放器的比特率转换算法带来了挑战,不过这些播放器仍有改进空间。几乎所有的播放器显然都需要经过 fMP4 方面的优化,但考虑到这种格式的新特性,这是个不错的开端。视频播放器生态系统对延迟问题越来越敏感,我们看到越来越多的开发工作致力于在所有平台上全面实现低延迟。


结束语

在 HEVC 格式测试和使用优化的开源播放器的其他试验方面,仍有后续工作需要完成,有关这些后续工作内容将在后续博文中补充介绍。但是,我们要强调的是,延迟并不是致命问题。您可以借助“标准”HLS、DASH 和 CMAF/fMP4 技术,通过一些方法,有效地将延迟降至最低水平。


优化的播放器能够使用目前的 HLS 和 DASH 工作流将延迟降低到 4 秒。这让我们可以从技术和经济的角度努力通过各种方式实现低延迟,因为这些技术完全符合 HTTP 1.1 和 HTTP 2.0 的要求,您无需部署昂贵的基于 UDP 的解决方案来降低延迟。如果您的业务需要低于 4 秒的延迟,即将到来的 Chunked CMAF 会为您带来降低延迟的新方式。它将编码器和源中正在产生的分段拆分成小区块,然后在播放器中播放,是一种即时的端到端工作流,非常接近广播领域中的实时 TS 概念,只不过它采用的是 HTTP。


到目前为止,10 秒的端到端延迟是最新标准,可满足您所有通过 HLS 或 DASH 连接的设备的播放要求。不过,如果您的业务需要,稳定的 5 秒延迟也已成为可能。所以,不要再等待了,赶紧打破 30 秒延迟壁垒!


————


第一部分:如何借助当前的自适应比特率技术降低广播延迟 – 定义和测量延迟


第二部分:如何借助当前的自适应比特率技术降低广播延迟 – 编码、打包和 CDN 分发的优化建议


第三部分:如何借助当前的自适应比特率技术降低广播延迟 – 视频播放器优化建议


第四部分:如何借助当前的自适应比特率技术降低广播延迟 – 参考架构和测试结果(本博文)


作者介绍:


Nicolas Weil


Nicolas Weil 是 AWS Elemental 的高级解决方案架构师。


TAGS: latency-broadcast


本文转载自 AWS 技术博客。


原文链接:


https://amazonaws-china.com/cn/blogs/china/compete-broadcast-latency-bitrate-tech4/


2019 年 10 月 08 日 15:57249
用户头像

发布了 1249 篇内容, 共 33.2 次阅读, 收获喜欢 34 次。

关注

欲了解 AWS 的更多信息,请访问【AWS 技术专区】

评论

发布
暂无评论
发现更多内容

ARTS week 1

时之虫

ARTS 打卡计划

2020年下半年计划

IT蜗壳-Tango

年度计划

好的软件工程原则

pydata

使用 Python 和 SudachiPy 进行日语分词

Roc

Python 日语 分词

使用 Markdown 制作五线谱

Roc

GitHub markdown 五线谱

使用<input>标签实现六个格子验证码输入框

brave heart

Java vue.js 前端

使用 Python 分析 Google Calender 日程

Roc

Python 总结 日历

RASP研发踩坑之agent 加载机制(1)

国服第一

Java JVM 类加载 RASP

你为什么“啃不动”你手中的技术书?

图灵社区

Java Python 算法 HTTP R语言

python实现·十大排序算法之计数排序(Counting Sort)

南风以南

Python 排序算法 计数排序

健身一周年:持续锻炼带来无法想象的改变

Breeze

学习 职业 专注 健身

学慢点儿,想深点儿

熊斌

学习

ARTS-weekly-31

落英坠露

ARTS 打卡计划

OBS推流学习笔记

IT蜗壳-Tango

直播 OBS 推流 B站直播

写给产品经理的信(4):你一定要做产品经理么?

夜来妖

生涯规划 产品 程序人生 产品经理 职业规划

ARTS week 2

锈蠢刀

RocketMQ - 如何实现顺序消息

Java收录阁

RocketMQ

微信推文无缝滚动是这样炼成的

喵喵侠

微信 前端开发 微信公众号 微信推文 图文混排

财富的大门给我开了一条缝

YoungZY

读书笔记 读书

数据与广告系列三:合约广告与与衍生的第三方广告数据监控

黄崇远@数据虫巢

数据挖掘 互联网 广告 移动互联网

软件开发生产率改进之我见(二)

清水

软件工程 软件开发 技术管理

教师节H5案例制作思路分享

喵喵侠

前端开发 H5游戏

2020全球首创币期权DAPP智能合约强势来袭,闪耀数字经济

极客编

栀子花,我们应该像你一样静静绽放

小天同学

个人感想 感悟 日常思考

提升输入效率第一步——切换双拼

dongh11

效率工具 提升效率 生产力 分享 有趣

假如孔乙己是程序员

顿晓

学习 程序员 孔乙己

源码分析 | Mybatis接口没有实现类为什么可以执行增删改查

小傅哥

Java 源码分析 小傅哥 mybatis 编程思维

Windows10 如何正确修改本地用户的名称及目录

喵喵侠

windows Windows 10 电脑故障 Windows技巧

点击劫持:无X-Frame-Options头信息(修复)

唯爱

Spring Security 两种资源放行策略,千万别用错了!

江南一点雨

Java spring springboot springsecurity

在 Go 中使用并发编程 - 第二部分

TuringTuring

golang 并发编程 协程 线程模型

第四部分:如何借助当前的自适应比特率技术降低广播延迟-InfoQ