HLS+CDN巧妙的流媒体技术组合

待学习概念:

  • 基于HTTP做的Hacks
  • MPEG-TS:MPEG-TS一种标准数据容器格式,传输与存储音视频、节目与系统信息协议数据
  • 视频格式H.264、H.265:都是一种编码方式,也就是一种数字视频压缩格式.其中H.265是对H.264的一种改进,仅需原来的一半带宽就可以播放相同质量的视频。那很明显采用H.265编码的时候电脑、手机、平板、电视、包括我们监控行业,都能在同等视频质量的基础上节省更多带宽和容量。
  • M3U格式和M3U8格式:播放列表。M3U文件是一种纯文本文件,可以指定一个或多个多媒体文件的位置。M3U8是Unicode版本的M3U,用UTF-8编码。支持的视频流编码为H.264,音频流编码为AAC。

已知概念:

  • HLS (HTTP Live Streaming) 存活的http流
  • M3U8文件保存的是一个播放列表 其中每个播放内容保存在一个MPEG-TS文件中
  • CDN运行机制:将不同客户端的来源,分配至不同的缓存服务器。如此一来,客户端可以更就近、缓存取得文件,而流量也都不需要集中在特定的服务器或机房,而可以分散掉,而分散化就是得到规模可扩充性的主要手段之一
  • MPEG-TS格式的额外负担比较重,因此,会提高整体传输时所需的比特率。按照规定格式传输数据,包含了大量的包头等额外信息,导致传输的实际内容更大。

优点:

  • 将视频内容压缩成为一个个小的片段,然后传递小的片段达到实时直播
  • 可以对播放列表中的TS片段进行预缓存,可以应对网络传输速度短暂、不稳定情况
  • 选择的HTTP协议穿透率比较好,因为它是浏览网站时所需的协议,因此,许多防火墙都会开放HTTP通过。倘若是其他的流媒体协议,不见得就会出现在防火墙的开放清单中。
  • 可以利用CDN的缓存,将集中特定服务器或者机房的带宽与流量分散,并且通过分发到不同的缓存服务器,使客户端可以更就近获取资源。
  • 根据M3U8播放列表 可以根据客户端的网络带宽情况分发不同码率的TS信息,保证用户播放的流畅性。

缺点:

  • TS格式的封装会造成额外传输成本

正文

透过网络流媒体,让用户可实时在线直播或点播多媒体数字内容,是目前相当热门的应用。其中,HLS协议和CDN的技术,扮演举足轻重的角色,让网站能够支持直播的功能与规模扩展.

在现今的网络环境,基于CDN(Content Delivery Network)来提供流媒体服务已成主流,不论是直播或是点播(即Video On Demand)。

直播指的是和内容来源同步播放,仅维持一定的时间差,像电视频道或是实况转播的节目,都是采用直播的形式。在直播的情况下,内容无法快转或倒转,只能随着时间播放。

而点播就不同了,点播的内容,都是早就存在好的文件,并不像直播内容,都是由直播内容来源实时的产生。也因此,二者运用的技术会有所差异。

透过网络流媒体,让用户可实时在线直播或点播多媒体数字内容,是目前相当热门的应用。其中,HLS协议和CDN的技术,扮演举足轻重的角色,让网站能够支持直播的功能与规模扩展.

在现今的网络环境,基于CDN(Content Delivery Network)来提供流媒体服务已成主流,不论是直播或是点播(即Video On Demand)。

直播指的是和内容来源同步播放,仅维持一定的时间差,像电视频道或是实况转播的节目,都是采用直播的形式。在直播的情况下,内容无法快转或倒转,只能随着时间播放。

而点播就不同了,点播的内容,都是早就存在好的文件,并不像直播内容,都是由直播内容来源实时的产生。也因此,二者运用的技术会有所差异。

HLS协议为HTTP提供网络内容直播技术

那么直播要如何基于CDN来做到呢?要回答这个问题,就得从HLS说起了。

HLS(HTTP Live Streaming)通讯协议是由Apple所提出的,现在虽然尚未成为IETF的标准,但是因为主流的平台,诸如iOS/Android等重要的手持装置平台都已经支持,使得它俨然成为在业界流通的准标准了。

那什么是HLS呢?简单的来说,HLS就是一种基于HTTP协议之上的流媒体协议,而且可适用于实时的直播用途。

HTTP的基本运作原则,就是一个请求可以取得一个文件。倘若想要取得一个不知道长度有多长的文件,像实时的流媒体就是如此,它很有可能不只是不知道有多长,甚至,它不会有结束。过去,有些人会基于HTTP做一些Hacks,例如设一个非常大的文件长度,来表示一个实时的流媒体。但是,有些多媒体文件格式,在流媒体内容还没结束时,形同文件没有完成,接收端也可能无法正确的剖析及使用。

所以,要怎么运用HTTP来做直播呢?

HLS的核心想法,是将流媒体的内容切割成一个个短的片段,例如,如果是影音内容的话,就把内容切割成约十秒左右的片段。不一定要切成十秒,究竟要切成几秒,还可以考虑其他的因素。通常,这十秒的片段的格式其容器(container)格式为MPEG-TS,所包装的视频格式为H.264 ,而音频格式为AAC。因此,整个影音的内容,就会被切割成许许多多的小片段。

当支持HLS的播放器要播放时,是从一个.M3U8格式的播放列表开始,在这个播放列表中,会有一连串的MPEG-TS文件的网址。此时,播放器只需要逐一的取出每个MPEG-TS文件的网址,并且透过HTTP协议持续取得每一个MPEG-TS文件,就能够持续的播放整个流媒体的内容。

有一点很重要的是,在播放器播放某个MPEG-TS文件的内容时,它可以取得整个清单中之后的MPEG-TS文件,甚至做一定程度的预缓存,这使得前一个MPEG-TS播放完成时,下一个MPEG-TS已经准备好了,因此可以达到流畅的播放。若是预缓存的份量够,则可以提供足够的缓冲效果,来应对有的网络传输速度短暂、不稳定情况。

正因为它是把整个流媒体的内容切割成多个小文件,因此,得以实现实时的流媒体。

但说是实时,也不是严格意义上的完全实时。因为,整个内容来源就算很快的完成格式的转换、压缩、及切割,客户端也要加载起码一个MPEG-TS之后才能播放。也就是说,起码也要再等十秒(若是单一个MPEG-TS切割成十秒的话),才能看到直播的内容。但是,绝大多数的应用情境,都可以接受一定程度的直播延迟,这使得HLS有机会成为网络流媒体直播的主要选项。

当初HLS选择基于HTTP是个不错的决定,怎么说呢?第一个考虑是,HTTP是一个「穿透率」比较好的协议,因为它是浏览网站时所需的协议,因此,许多防火墙都会开放HTTP通过。倘若是其他的流媒体协议,不见得就会出现在防火墙的开放清单中。

CDN技术的应用,协助快速扩展执行规模

此外,还有一个重要的好处,就是有许多扩展规模的技术,都是基于HTTP而做的,这是为了开发能承载高流量、大规模的网站而研发的,如今都可以运用在HLS服务的扩展规模之上,例如CDN就是其中之一。

当流媒体内容经过如上所描述的一连串程序,产生一个个MPEG-TS文件之后,即可将它们送至CDN之上,接着再利用CDN的机制,将不同客户端的来源,分配至不同的缓存服务器。如此一来,客户端可以更就近、缓存取得文件,而流量也都不需要集中在特定的服务器或机房,而可以分散掉,而分散化就是得到规模可扩充性的主要手段之一。

此外,同一个内容,还可以被编码成不同的比特率(bitrate),也就是会提供不同的质量。因为透过网络连接上流媒体服务的客户端,可能会有各种不同可能的联机带宽,针对不同联机带宽的客户端,就可以藉此提供不同的质量,使得它们都可以流畅的观看。

而使用HLS的好处之一,也包括了播放过程中,可根据客户端联机带宽变化而调整播放质量。

当播放时,发现客户端的带宽持续不足的情况,便可以将它导向另一组比特率较低的MPEG-TS文件,以提高它播放的流畅度,而这个转换的动作,在HLS的设计下,是可以动态进行的。所以,这样的设计,有助于移动设备在多媒体流媒体的播放,因为移动设备的联机质量通常变化动态,会比个人计算机来得还大。

所以,经过这样的说明,就不难了解HLS和CDN之间的关联性。倘若只有HLS,最终还是必须面临传统集中式架构的问题,即带宽使用集中、无法分散的缺点。但正如前面所述及的,选择了HTTP,等于选择了为HTTP所开发出来的各种扩展规模的技术,包括CDN在内。这使得立足于CDN的HLS,有了优秀的规模可扩充性。

现在,许多云端平台都提供CDN的服务,例如Amazon的CloudFront,这更便于流媒体服务的提供者,因为只需将流媒体内容直接送往CDN,即可处理掉扩展服务规模的许多技术议题。在这里,云端的平台技术,对实时流媒体服务,起了很大的作用。

应用HLS+CDN的成本不一定低

此外,即使不是实时的流媒体,也可以使用HLS+CDN的技术组合。也有不少「点播」的服务者,使用静态文件部署于CDN的方式,来提供点播的文件,例如使用 .MP4 做为格式,内含H.264 及AAC格式的视频及音频。

这也行的通,但是MP4 的格式对播放器来说,需要多花点时间,才能取得相关的一些索引信息,因此,在加载时间上就不像HLS那样的短。在播放时,需要更多的时间才能开始收看。此外,这种方式在CDN上,会比HLS成本更高。

但HLS也并非毫无缺点,举例来说,MPEG-TS格式的额外负担比较重,因此,会提高整体传输时所需的比特率。

总而言之,HLS的设计搭上CDN基础设施的渐趋完备,使得它成为目前多媒体流媒体服务的主流选项。以现在服务的质量及规模来看,这个组合会流行好一阵子。

下一篇