优化延迟的最佳视频传输方案(一)

流媒体服务逐渐成为全球媒体和娱乐业务的核心,根据目前市场的数据,由于增长率是传统电视的10倍,OTT视频已经占到了行业总收入的15%,预计到2022年将占据市场收入的三分之一。

要想实现视频流的最优化传输,就必须实现在传输的各个阶段都协调工作,达到降低延迟最优的效果。首先,说明一下在传输过程中的第一个阶段的优化:第一公里(the first mile)传输中的优化。

PART1

分发链前段的优化

从分发链的前端开始

在视频传输的每一步都必须确保能够将内容传播到链中的下一个节点 - 并且达到生产者期望的质量水平,而且由于现在的OTT服务已经成为内容提供商及其分销商盈利的核心,因此对质量的要求比以往更高。

这种新的商业模式要求在任何显示器上能够以传统电视的低延迟和高质量来访问任何视频流,同时按需观看的OTT内容开始播放的速度能够与传统VOD内容一样快。这需要在第一英里的传输阶段满足具有完全备份冗余功能的卫星和传统光纤传输的性能参数, 并且具有快速识别和解决问题的能力。

图1. 视频直播系统通过多种方式向消费者传输内容

了解视频分发的端到端环境

对于希望最大化第一英里传输性能的提供商而言,确定最佳方案的第一步是了解延迟,质量,冗余和其他因素的要求和关键性能指标(KPI)。分发阶段涵盖了从后期制作输出到OTT传输内容的所有路径,包括基于IP的管道到OTT附属机构以及用于直接到消费者(DTC)操作的内容交付网络(CDN),还有传统的向多频道视频节目分发机构的网络。

对于线性内容,延迟必须最小化到传统电视频道与互联网的传输时延几乎没有差异,这意味着互联网连接设备在广播和接收之间的30秒延迟必须减少到大约10秒。虽然线性传输的延迟要求不适用于按需传输的内容,但无论情况如何,都必须考虑更高的要求,包括服务目标,启动时间,图像质量,重新缓冲和服务可用性等。

后期制作内容格式

保持分辨率,颜色深度,位深度和其他源材料参数的端到端保真度是为后期制作播出准备高质量内容。但是,在准备OTT分发的内容时,需要注意一些细微差别。

以隔行扫描的内容为例。虽然许多代码转换器能够对隔行扫描的电视节目进行去隔行扫描,但最好在source处执行反交错操作以保持质量。此外,反交错有助于通过从改变原始状态来修改内容(如帧缩放)进而减少失真。

前期编码

将制作的信号转换为第一英里分发的格式有两种主要方法:母版编码(mezzanine encoding)和直接编码( direct to origin encoding)。

通过母版编码,内容的一个单独片段在第一英里内发送到获取网络(ingest network),在那里准备传输。内容提供商必须关注最终用户设备的特点 - 比特编码深度,帧速率,宽高比和动态范围设置 - 以满足提供电影和电视节目的要求。夹层编码输出的比特率旨在实现最大化观众体验,实现所需的最高质量。使用的特定比特率/编解码器/设置组合将是内容准备链中的第一英里传输的带宽、质量目标和预期的迭代损失的函数。精心设计的编码转换器的一般规律是对类似的编解码器有预期25%-40%的迭代损失。此外,使用标准化编解码器可确保与常见的转码服务兼容,并可以利用经过验证的测试分析指标。

Origin处编码的最佳方案是将内容以多比特率配置文件或自适应比特率(ABR)流使用的文件一起传输到origin处的服务器,以在每个设备能够中获得最佳质量呈现。这通常涉及使用至少七种不同的比特率配置文件,除了诸如3G和2G移动网络之类的场景,因为接入带宽会限制可能需要四个或五个。

选择正确的IP传输

在选择IP传输模式时,延迟最小化和避免质量下降应该是主要目标。提供商应首先考虑实施最新的HTTP / 2。配置HTTP的内容使得提供商可以根据基于传输控制协议(TCP)的ABR流传输内容到origin服务器上的获取点 - 消除了编码转换器的处理步骤。

TCP历来确保IP数据包到达其目的地并在客户端呈现时能够正确排序,从而具有高可靠性,但如果数据包流中断,随着更高比特率的增加会导致高延迟。视频信号通过互联网传输的距离越长,中断和重新缓冲事件就越多。

另一种传输模式 - 用户数据报协议(UDP) - 是一种无连接协议,不需要发送方和客户端之间的通信。与TCP相比,UDP实现了更低的延迟和更好的带宽利用率,但如果在数据流中阻塞或丢弃,则会丢失数据包。而最近的UDP协议的改进,包括IETF QUIC标准,可以在不牺牲TCP可靠性的情况下降低了延迟并提高了利用率。

满足质量控制要求

对第一英里传输的质量控制始于多路径冗余,这确保了内容可以在不中断所有摄取点的情况下传输。而对于全球直播活动,有数百万观众,如奥运会或世界杯,提供商应该至少有两条完全不同的路径,实际上三条或更多路径用于提供内容。常规的线性传输也需要持续的性能,这会增加连续时间段内数据传输中断的风险。应将双路冗余模型视为基线,根据频道或内容,运营商可以选择考虑用于直播的三路径冗余模型。

无论选择何种冗余,提供商都必须通过第一英里的分发点保持持续的性能监控和分析 - 必须确保与互联网服务提供商(ISP)一起解决任何可能导致糟糕用户体验的问题。内容提供商可以通过监控,分析和缓解功能来应对这些运营挑战,这些功能对于保持对端到端性能的控制至关重要。

PART2

内容准备

接下来介绍的是有关优化延迟中的另一个步骤,内容准备方面的优化。

OTT视频的转码和比特率配置文件创建

从根本上说,转码过程要求媒体内容以最高质量准备并在传输前进行优化。这需要为所有连接互联网的观看设备准备流的切片,比特率,比特深度和成帧策略。在转码过程中产生的视频再现质量对于在传送和播放期间的视频质量至关重要。但是,在所有情况下创建最高质量的视频再现是几乎不可能的,根据具体情况,视频质量可能过高,导致带宽浪费;或者它可能太低,导致像素化播放。

优化比特率阶梯以实现最佳视频播放

为了满足播放的高质量,在转码过程中应特别小心,以便为给定的内容选择最佳比特率阶梯。一些内容提供商选择一种通用的方法,为其整个VOD目录创建类似的比特率阶梯,但这会导致不必要的存储和传送成本,并导致不理想的播放质量。

视频点播的最佳方案需要上下文感知编码,该编码为目录中的每个标题建立最佳比特率梯形图。每个场景都以多个质量等级生成,比特率根据需要进行调整。使用这种方法,播放期间的感知质量是相同的,但需要相对较少的带宽。内容提供商也越来越多地使用机器学习方法来选择最佳比特率。

实时流式场景的最佳实践仍然是为每个人创建一个比特率梯形图,可以针对某些查看场景进行修剪。修剪可用的再现数量可以通过清单操作或高级播放器逻辑进一步处理。

解决下一代编解码器难题

虽然H.264 / AVC长期以来一直是视频流中使用的主流编解码器,但4K超高清(UHD)的出现使得内容提供商开始关注新兴的编解码器,其中包括H.265 / HEVC,与AVC相比,压缩效率提高了至少50%。

由于4K UHD流的质量优势以及最新Apple智能手机和电视内置的支持,HEVC在大规模UHD可用之前就获得了关注。随着内容提供商和分销商开始扩展编解码技术,HEVC也在编码器方面获益。

话虽如此,可HEVC还是没有得到整个行业的全面认可,比如AVC仍然将是近些年的主流编解码器,而版权费用也是HEVC的障碍,同时Google的免税版VP9和开放媒体联盟的AV1等高性能选项都得到了各种设备,网络浏览器和行业领导者的支持,给HEVC带来了激烈的竞争。

所有这些不确定性都表明在选择编解码器时需要关注当下行业发展的形势,由于并非所有编解码器都支持所有设备,因此建议在经济足够时考虑多个编解码器。一般情况下是考虑在节省交付成本达到存储和编码的增量成本时可以用新的编解码器。任何用例的经济因素应始终是选择正确的混合编解码器,以支持将优化传递到所有目标设备。

OTT视频的准备和包装

对于给定的内容,每组编码的再现必须与manifest文件打包在一起,允许目标客户端使用与manifest中一致的编码格式来获取和呈现内容。

播放器还必须明白表征自适应比特率(ABR)manifest文件的一些特殊内容,这包括创建清单文件的子集,比如这些清单文件利用元数据来指导音轨字幕和语言字幕,选择数字版权管理模式,描述符将高级功能与特定内容段相关联,以及动态广告的展示位置选项等等。

由于市场中MPEG-DASH和HLS的大规模使用 – 同时随着对Microsoft的Smooth或Adobe的HTTP动态流媒体(HDS)的支持逐渐消失 - 最佳方案是分发商使用HLS或用于绝大多数用例的DASH流格式。但是,仍然存在一些需要使用Smooth的特殊情况。标识为HLS中的主播放列表和DASH中的媒体呈现描述(MPD)的主清单文件能够向播放器提供关于音频和视频编解码器的信息,其中还包括比特率配置,segment大小和顺序,以及与字幕有关的细节和广告等内容。

必须呈现和同步所有这些元素,以确保在客户端设备上进行精确,流畅的播放。通常使用具有HLS和DASH的fMP4容器以及最大化CDN效率的最佳方案是利用新兴的通用媒体文件格式(CMAF)。

CMAF的出现

通用媒体应用框架(CMAF)可以使用fMP4容器对多个比特率配置文件中的视频进行均匀分片编码,以便通过HLS或DASH进行流式传输。CMAF提供了一个轻量级框架,它不会引入新各方案,而是以新的方式组合现有格式和标准。随着2017年实现正式标准化,行业中的以后实践就都需要考虑CMAF这种新格式。

对于按需播放的场景,最佳方案需要使用DASH或HLS,fMP4容器和CMAF。内容提供商可以利用CMAF中打包的一组音频和视频文件以及引用该文件的两个清单(一个用于HLS,另一个用于DASH)。这有助于降低内容准备和存储成本,同时通过提高缓存命中率提供更好的CDN效率。

在播放实时流的情况下,最佳方案是使用DASH或HLS,fMP4容器和CMAF。在按需播放的场景中,CMAF使内容提供商能够利用一组带有两个清单的实时音频/视频文件来引用该文件。但是,在实时流媒体的情况下,CMAF可以帮助内容提供商实现更低的内容准备和摄取成本。最佳方案包括将原始摄取源与原始服务器合并到ISO,而不是TS和ISO,这可以将带宽减少一半。

CMAF还具有用于实时流的可选分块编码模式,当与通过origin和CDN的分块传输支持相结合时,可以将端到端延迟减少到几秒,并且还允许延迟与切片持续时间分离。此选项为内容提供商提供了一种途径,可以在不降低切片持续时间的情况下实现更低的延迟,同时提高质量。

托管与内部原始基础设施

在转码和打包之后,将打包内容摄取到可由CDN访问的源服务器上是下一个关键的优化步骤。为了支持大量受众的实时线性视频服务,最佳做法包括使用编码器将内容推送到原始设备,以处理CDN基础设施上的内容的大量呼叫量。最佳方案要求原始服务能够根据网络条件,受众位置和其他因素动态找到最佳入口点;并且还支持最佳传输模式,以最大限度地减少延迟而不会降低质量。对于按需播放的场景,建议使用提供高度可扩展基础架构的原始服务,与分销商工作流程协同工作,以优化高性能视频的存储。

使用自己的原始基础设施的提供商必须具有足够的容量以pull模式运行,以处理来自所有CDN的所有呼叫,以及在主要源设施可能发生故障时的单独备份设施,切换到备份还需要自动响应功能,全天候监控和高性能传输连接。

最大化OTT视频的质量保证

OTT分发的编码和打包需要保证这些过程始终按要求执行。必须采用性能监控和分析工具来提供所需的全面可见性:在问题导致中断之前识别问题;比较输入和输出质量;确认每个视频节目都能达到延迟和期望质量;并验证工作负载是否正确分配以避免编码转换器上的过载

参考资料

[1]http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Best-Practices-for-Premium-Video-Streaming-Part-1-124826.aspx

[2]http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Best-Practices-for-Premium-Video-Streaming-Part-2-Content-Preparation-125693.aspx

原文发布于微信公众号 - 媒矿工厂(media_tech)

原文发表时间:2018-10-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏安全领域

给道德黑客的十大建议

你是否每天都突破各种防火墙?睡觉都在想着利用漏洞?可以轻而易举入侵加密网站?为了人们的利益而做这些事?如果你对这四个问题的回答都是肯定的,你就是道德黑客——或者...

15220
来自专栏CSDN技术头条

2017开发者生态报告,学什么语言最有前途?

JetBrains 在 2016 年底至 2017 年初期间,对 5000 多名开发人员进行了调查,以研究最新的开发生态。 最近,调查结果已公布:Java 被...

266100
来自专栏安智客

8张图带你玩耍Mbed OS!

对于MbedOS的认知一直停留文档上,安智客上周末闲逛淘宝手贱买了一个支持MbedOS的开发板,到货了忍不住玩一玩,也就是helloworld!各位见笑了!整理...

17020
来自专栏ThoughtWorks

如约而至|2018年5月期技术雷达正式发布!

ThoughtWorks每年都会出品两期技术雷达,这是一份关于技术趋势的报告,由 ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出,它以独...

11610
来自专栏姬小光

如何洞悉隐性需求

俗话说,计划赶不上变化快,无论需求文档做得如何细致,考虑得如何周全,总会有些难以预料的需求变更在每天困扰着我们。开发人员苦恼,产品运营人员更苦恼,毕竟谁也不愿意...

10030
来自专栏Java学习网

盘点五类最受欢迎的开源云项目

  Linux.com和The New Stack曾联合起来做过一项调查:你认为的最受欢迎的开源云项目是哪些?调查涵盖了hypervisors、IaaS、Paa...

51970
来自专栏大数据文摘

一个披萨电影夜,你到底泄露了多少个人数据?

16540
来自专栏腾讯移动品质中心TMQ的专栏

探索式测试基础系列--初恋的味道

一、探索式测试基础系列 1、背景 在移动互联网时代,敏捷开发是主流的开发流程,功能的快速迭代让我们面临的问题就是如何应对各种需求变更,如何提升测试效率,要解决以...

23680
来自专栏程序人生

Phoenix 1.3,迈向正确的道路

距离 1.2 发布已经有一年多,而 exlirconf 2016 McCord 宣布 1.3 的特性也已过去半年,phoenix 1.3 依旧犹抱琵琶半遮面,迟...

397150

有效的云服务报警系统

原文作者:Venkat Pothamsetty

29510

扫码关注云+社区

领取腾讯云代金券