ANIL MURCHING Azure 媒体服务高级项目经理
自从我们去年发布 Azure 媒体服务的直播流媒体以来,您已经可以访问这一可即时伸缩且始终可用的流媒体解决方案,许多广播公司反复使用该解决方案为百万客户提供直播事件。您可能已经阅读了我同事发表的有关 使用 Azure 管理门户 或 我们的 .NET SDK 来管理直播事件的博客以及有关如何生成实时订阅源的博客。但在以前,为了使用直播流媒体,您需要使用本地编码器来生成自适应码率视频流,然后将此其推送到云。借助实时编码的预览版,可以将单码率实时订阅源发送到 Azure 媒体服务,此订阅源在云端可以编码成自适应码率流媒体,之后可以将这些内容以 MPEG-DASH、Microsoft Smooth Streaming、Apple HLS 或 Adobe HDS 格式提供给各种类型的客户。
在本博客中,我将简要介绍此实时编码功能,此功能使 Azure 媒体服务可以实现以下功能:
对直播事件进行流式处理时,您的目标是在各种网络条件下都能将高品质的视频提供给客户可能持有的各个设备。有一种解决方案可以解决质量和网络条件的问题: 自适应码率流媒体 。它解决多个设备(及其功能)的问题的方法是有一个重新打包的系统,例如 动态打包 。
自适应码率流媒体的工作原理是以不同的分辨率和码率将视频编码成多个视频流媒体,同时使它们保持同步。另外,对于直播事件,还需要将处理实时传入视频编码所造成的延迟保持在可接受的范围。这个实时视频压缩过程就是实时编码,此过程很耗时。要对直播事件进行流式处理,在硬件方面,可能需要性能较好的CPU(甚至必须采用编码效率更高的 GPU 设备)。此外,还需要生成多个(6 到 10 个)视频媒体流,这意味着您还需要大量带宽才能将这些流媒体推送到 CDN,这样,便可将该事件提供给客户。您的基础设施成本开始增加…
Azure 媒体服务的实时编码是基于云的工作流,它可以解决此类基础设施问题。借助此功能,只需将单个(高品质)视频订阅源发送到 Azure 数据中心,该服务处理计算密集型工作,将视频编码成自适应码率流媒体。这意味着,您可以从远程位置(只需为稳定快速的 WiFi 或移动网络支付费用)、内置在摄像机中的编码器或者功耗较小且成本较低(甚至免费)的编码器中处理直播事件。我们的服务有即时缩放功能,这表示您可以处理事件计划中的发生的峰值,而您只要负担使用服务时产生的费用。
您可以通过下列步骤来设置实时编码以提供直播事件:
注意:您可以通过后续博客文章来获取有关 API 和配置步骤的详细信息。
实时编码支持以下输入协议:RTMP、RTP (MPEG TS) 和 Smooth Streaming。您可以提供以下实时订阅源:使用 MPEG-2(高达 422 Profile)或 H.264(高达 High 422 Profile)编码视频,以及使用 AAC-LC(多达 7.1 个通道)、Dolby® Digital/AC-3(多达 7.1 个通道)或 MPEG Audio(第 II 层和第 III 层,最高到立体声)编码音频。
实时编码器支持范围介于 4:2:2 到 4:2:0 之间的色度二次抽样(chroma subsampling)、去隔行(de-interlacing)、音频通道下混音(audio channel downmixing)、音频重新采样(audio resampling)以及音频动态范围压缩(audio dynamic range compression)。
在输出方面,实时编码器可以将视频编码为 H.264(高达 High 4:2:0 Progressive)并将音频编码为立体声或单通道 AAC(LC、HE v1、HE v2 Profile)。
实时编码器还支持传送 EIA/CEA-708 隐藏式字幕(closed captions)(如果输入视频订阅源中存在的话)。
在广告通知方面,实时编码器通过 API 调用来支持输入;如果输入协议是 RTP,则通过频带内(in-band) SCTE-35 SpliceInsert 和 TimeSignal 命令来支持输入。输出方面,我们的服务可以发送 HLS Playlist Tags(SCTE-67)、Smooth Streaming Sparse Tracks (SCTE-35) 以及 HDS CueInfo Elements。
您可以通过下列协议之一将输入实时订阅源发送到通道:
通过 RTMP 将实时订阅源发送到通道时,具有以下限制:
如果您计划使用 RTP 来提供直播流媒体,您的网络连接应满足以下条件:
建议使用以下两种方法。无论选择哪种方法,都应该选用第 1 层网络提供商。可以在 此处 找到第 1 层网络提供商的列表。
您可以将公共互联网和 BGP 对等项上的 RTP 用于 Azure 网络。这种情况下,一个或多个网络提供商会提供“互联网能力” (Internet capacity),有时称为高速 IP (HSIP)。视频数据通过公共互联网来传输,并且需要在某个网络提供商的互联网IP 边缘与并置的Azure 网络之间进行交叉连接。此并置取决于网络提供商和 Microsoft,可以从 PeeringDB 中获取。网络提供商负责按照业内标准的服务级别协议将互联网服务交付给 Azure。这是我们在当前 美国国家广播公司体育台/索契冬奥会解决方案 中使用的方法,此方法通常可以降低网络成本。
您可以在专用的私有网络上使用专为传输常规数据(而非特定于视频的数据)而设计的网络解决方案。大多数情况下,网络提供商通过托管服务包来支持此方法。您可能只需要使用此服务包中的一小部分服务。此类托管服务的优点是使用增强的服务级别协议来提供和管理端到端交付。此类别包含两种服务:
如果您通过 RTP 发送实时订阅源,将会使用以下常见的传输中编码/容器和协议:
通道启用实时编码后,正在处理视频的管道中会出现一个组件,您可以操控该组件。在我们的服务中,您可以将通道插入版面和/或广告信号发送到传出的自适应码率流媒体中。版面仍然是图像,在某些情况下(例如在插播广告期间)可用于覆盖输入实时订阅源。顾名思义,广告信号是指与时间同步的信号,您可以将其嵌入到传出的流媒体中,用于通知视频播放器采取特定操作,例如,在合适的时间切换到一则广告。有关满足此用途的 SCTE-35 信号发送机制的概述,请参阅此 博客 。以下是一个典型的场景,您可以在直播事件中实施该场景(后续博客文章中将提供示例代码和 API 详细信息)。
启用实时编码后,当实时订阅源到达通道时,您可以获取其预览。这是一个非常有用的工具,可用于检查实时订阅源是否真正到达通道。您可以通过 API 访问缩略图。
在本博客中,我向您介绍了 Azure 媒体服务中的实时编码功能。在接下来几天,我将针对下列主题发表更多文章:使用 Azure 管理门户进行实时编码、配置本地编码器来生成输入实时订阅源,以及如何控制版面和广告。在此期间,如果您对此功能有任何问题,请将问题发送到 AMSLiveD@microsoft.com
本文翻译自: http://azure.microsoft.com/blog/2015/04/13/an-introduction-to-live-encoding-with-azure-media-services/