流媒体
现代科技不仅发展迅速,而且其增长简直是爆炸性的。专业技术领域如此之多,以至于一个人不可能完全理解组合起来产生最新流行语的子系统的复杂性。正如我们现在在首字母缩略词内部使用首字母缩略词来简洁地描述最新的创新一样,我们将数百人年的工作封装成一个单一的抽象表达式,然后将这些抽象组合在一起,创建更大、更复杂的系统,而这些系统本身很快就成为更大难题的另一部分。
一个合乎逻辑的问题是“是否有人需要理解如此详细的系统?” 我们难道不能只将所有黑盒子拼接在一起,只知道它们的输入/输出 (I/O) 规范,就能获得可行的解决方案吗? 答案显然是否定的。我们不需要理解我们使用的每项技术的最微小的细节,但是如果我们想要最好地利用我们的技术,我们必须比仅仅看到每个子系统的可见规范更深入地研究。
多媒体内容交付是需要这种细致理解的任务的一个很好的例子。多媒体只是两种或多种类型的通信媒体的组合,例如音频、视频、图形、文本或任何其他可以刺激人类感知感官的元素。本文着眼于流媒体——使用基于计算机的技术进行时间相关的多媒体数据交付,而不是时间无关的数据交付的过程——来展示为了使这些子系统协同工作以达到期望的结果,必须对许多复杂的技术进行相当深入的理解。流媒体过程中概述的步骤可以线性地呈现,因此,可能看起来是独立的黑盒子。然而,每个步骤的理想实现都需要了解并考虑过程中的所有步骤。
流媒体过程只是一种通信数据的方式。这种通信可以来自许多来源,并且可以定向到许多目的地。这些通信的目标称为接收器。每个接收器也可以是其他“下游”接收器的数据源。源/目的地流媒体流的四种排列是:一对一、一对多、多对一和多对多。这四种组合中的每一种都需要一组通用的流媒体服务,并根据源和目的地组合的特定要求进行调整。互联网工程任务组 (IETF) 已经开发了协议来支持流媒体的各个方面,而行业才刚刚开始全面实施这些设计。
在硬件方面,系统在设计时应考虑到增长和可扩展性。对更高性能组件的相对较小的前期投资可能会在后期节省大量资金。升级实际上并不影响系统中性能瓶颈区域的组件也很容易浪费钱。我们将遵循从数据创建到传输到接收器的逻辑路径,并在过程中讨论细节。
有一个完整的行业致力于创建多媒体数据的任务。从历史上看,昂贵的、高度专有的工作站创造了大多数高端“好莱坞级别”的多媒体。PC 革命为以前需要昂贵解决方案的许多任务提供了低成本的替代方案。这些解决方案最初是在 Macintosh 计算机上,后来迁移到基于 Windows 的系统,但它们仍然是专有系统,使用户依赖于供应商。
最近出现了向 Linux 迁移的趋势。除了 Linux 的“免费啤酒”方面之外,最终用户还看到了 Linux 的真正优势,因为他们可以将自己从对任何单一供应商的依赖中解放出来。时间关键型内容创建是好莱坞制作的标志,因此公司不能依赖于即使是最合适的供应商。为了保护自己的业务,他们必须能够自己完成整个工作。
视觉效果协会是一个行业组织,约有 24 家成员公司,每家公司都以执行创建多媒体数据所需的各种任务为基础开展业务。该协会已宣布希望在未来几年内完全迁移到 Linux,但为了实现这一目标,Linux 操作系统还需要做很多工作。幸运的是,流媒体技术向 Linux 操作系统的迁移正在顺利进行中。
如果您想提供流媒体服务,整个过程都取决于您打算流式传输的数据。您会流式传输实时视频吗? DVD 或 CD-ROM 内容?数据是否包括计算机生成的图形图像或几种媒体类型的组合?为了生成您打算流式传输给客户的最终数据,将如何混合和处理数据?这些问题必须首先在战略层面回答——您的计划业务是什么?然后必须根据可用的设备、技能、时间和财务资源来研究答案。这些参数不仅必须从数据创建本身的角度考虑,还必须从您必须为整个解决方案提供的剩余服务的角度考虑。例如,如果您的业务是将录制的内容流式传输给付费客户,您最好了解您的目标受众的需求。他们会按次付费观看,还是会期望获得“免费”内容?您必须使用流媒体支持的客户端技术组合是什么?这些以及我们在探索流程中的每个步骤时都会涉及的许多其他问题,都会影响您对系统中所需的软件和硬件的决策。
什么是数据编码?为什么这是必要的?对于计算机交付而言,最重要的编码过程要求将数据转换为数字形式。现实世界是基于连续或模拟数据的。当今使用的大多数计算机都是基于数字技术的。系统中的所有内容都必须用 1 和 0 的某种组合来表示,因为计算机所能做的就是打开 (1) 或关闭 (0) 单个电路。
还存在另外两个因素,要求编码不仅仅是简单的模拟到数字数据的转换。由于典型数据是受拥有的,并且当前大多数观点认为必须保护数据免受非法复制和分发,因此数字化数据流通常在编码过程中或编码后进行加密。各种通信链路上的数据流速度的技术限制也要求数据在大小上被减小或压缩,以便现有硬件可以平稳地实时执行流媒体过程。
您用于编码内容的方法取决于编码软件和硬件、CPU 处理能力和速度、网络技术以及数据存储和检索要求。如果您打算将数据流式传输到您直接控制下的受众,您的问题将更多地集中在所需的技术上。如果您的业务是将任意数据流式传输到任意客户端,除了技术之外,您还必须考虑标准、事实标准和特定的客户要求。
术语 编解码器 指的是用于编码和解码您的内容的编码器/解码器对。大多数编解码器都是专有的,并且由于已使用这些隐藏格式编码了大量数据,因此行业可能需要一段时间才能完全转向开放标准,如果真的会转向的话。当今最流行的专有编解码器来自 RealNetworks、Microsoft 和 Apple。
然而,正在兴起一种强大的向运动图像专家组 (MPEG) 格式发展的趋势。MPEG 格式的优势在于被公认为国际标准,并且它们以最小的数据质量损失提供最高的压缩比。有两种常用版本,MPEG-1 和 MPEG-2,但 MPEG-4 是一种专为交互式多媒体应用程序设计的新格式,很可能成为标准编解码器,直到 MPEG-7 发布(可能在 2001 年)。最流行的版本 MPEG-2 包含专利 IP,可以通过执行单个 MPEG-2 专利组合许可来使用(在美国,http://www.mpegla.com/)。
尽管许可不是免费的,但编码和解码算法是开放的,并且可以创建开源实现。MPEG LA 在今年 9 月宣布了一项计划,“旨在通过一个许可证,为实施国际 MPEG-4 系统标准必不可少的专利提供公平、合理、非歧视性的全球访问”。使用 MPEG 等开放标准至少解决了公司编码其多媒体技术的一个主要担忧。他们将来不会被迫返回任何特定供应商寻求服务。涵盖 MPEG 技术的专利如此之多,以至于需要重大的工程突破才能产生具有竞争力的免费许可替代方案。
在决定使用哪些编解码器之前,您是否需要彻底理解每个编解码器背后的技术? 我会说,完全理解不是必要的,但您当然应该理解到足以估计生成的文件大小并考虑到任何编码和解码开销的程度。您还应该在决定使用哪些编解码器之前了解客户的需求。专有编解码器通常除了初始编码平台之外,对任何平台都没有客户端支持。考虑任何技术许可问题,并特别注意如何处理因使用特定技术而可能累积的财务责任也非常重要。
一旦您拥有创建编码内容所需的硬件和软件,请考虑如何存储您的内容以按满足客户需求的速率进行传输。如果您的数据来自实时、直接媒体馈送(例如来自摄像机),则当前的编码硬件通常只允许每个编码卡一个实时馈送,并且您的存储要求只是在编码数据传递到网络接口卡 (NIC) 之前保存编码数据所需的系统 RAM。对于一对一或一对多数据流,这种类型的内容交付非常简单。由于您提供给客户的每个实时馈送都需要一个单独的编码卡,并且通常需要一台专用计算机作为该流的服务器,因此可以使用简单的加法来计算增加的成本。
如果您的数据是预处理的,并且在稍后计划的流媒体时间或客户端的视频点播 (VOD) 时流式传输,那么您用于这些功能的硬件和软件可能会成为通过系统的数据流的关键瓶颈。这是一个示例,演示了您需要的信息类型,以便估算您的系统资源。
假设您的业务预期最多为 10,000 个客户提供连续流媒体一小时,但每天有两个小时的峰值时间,预计 80% 的客户可能在线。假设平均每个客户需要 300 KBps 的流媒体来显示无闪烁、不间断的多媒体内容。还假设平均而言,在任何时候都有 100 个不同的内容文件正在从 5,000 个标题的池中访问。
查看峰值需求设置了我们的数据存储和检索子系统的上限要求。我们决定不向客户提供 VOD,而只允许他们收听一些计划的广播。这项战略决策使我们能够更重视同步内容的不同片段的数量,而不是最大客户数量。假设您的网络路由器可以处理多播,即向尽可能多的 IP 地址发送相同的信息,这些地址可能注册接收数据(多播才刚刚开始通过一些本地 ISP 提供),我们有足够的信息来估算存储和检索子系统的要求。我们的总存储要求是标题数量、每个文件的平均运行长度以及数据流式传输的比特率的乘积。在这种情况下,它是 5,000 个文件 x 每个文件 3,600 秒运行长度 x 300,000 bps/8 位/字节数据 = 675GBs 的存储空间。
为了跟上预期的客户需求,我们的数据必须以多快的速度从磁盘驱动器传输到 NIC?为了计算这个答案,我们计算同时从磁盘读取的不同文件数量与平均数据速率的乘积:100 x 300,000 / 8 = 每秒 3.75MB。如果我们决定提供 VOD,那么这个数字可能会增加 8,000 倍,即峰值用户数,他们会要求在完全随机的时间开始观看流媒体,这会使我们对磁盘驱动器需要每秒 30GB 的数据!我们很可能希望通过一些智能管理方法来降低带宽要求。例如,我们可以选择仅在每分钟开始时允许新的视频开始。这对最终用户来说是相当透明的,但将通过允许我们利用系统中的多播功能来提供帮助。我们现在必须考虑磁盘驱动器的大小和数量、驱动器的最大平均数据传输速率以及 PCI 总线的最大数据处理能力,数据必须在 PCI 总线上通过两次才能被流式传输(一次从磁盘驱动器到主机,然后再次跨总线到 NIC)。
我们找不到一个磁盘驱动器来存储这么多数据,因此我们必须想出一个方案,将存储空间分配到至少几个驱动器上。我们也知道,如果客户的节目在播放中途中断,他们会非常沮丧,因此我们必须创建某种类型的备份计划来应对可能的磁盘故障。这些问题的解决方案通常通过 RAID 系统和复杂的负载平衡软件来处理。
如果使用 RAID 0 解决方案,其中两个相同的驱动器包含相同数据的镜像,我们如何以最有效的方式访问数据?每个磁盘控制器通常都包含专有的控制软件,该软件试图优化来自多个磁盘驱动器的数据流。这是一个非常复杂的问题,没有通用的“最佳”解决方案。如果只访问两个文件,我们可以从磁盘一读取一个文件,同时我们寻找正确的磁道以从磁盘二读取下一个文件。现在我们添加对文件三的请求。从磁盘一获取文件三还是从磁盘二获取文件三更有效?也许最好是交织来自两个磁盘中的每一个磁盘的扇区,但请记住,磁盘驱动器上最慢的操作是磁道寻道时间。
我们可以通过对文件放置进行一些智能管理来帮助调整我们的系统。我们可能会将流行的文件加载到我们系统中的所有磁盘上,但仅将不太活跃观看的内容加载到两个不同的磁盘驱动器上。这种方法有助于负载平衡,并减少必要的冗余所需的总存储空间。
我们对磁盘和磁盘控制器的运行方式了解得越多,我们就越能调整我们的系统以获得最佳性能。在这里,我们也不需要确切地知道我们的存储和检索子系统是如何工作的,但我们了解得越多,我们就越好。
您的系统和互联网之间的最后链接由您的网卡提供。尝试设计您的系统,使多媒体内容具有通往互联网的最短路径。注意您的网络和每个 NIC 中的总带宽限制,并记住,由于总线速度限制,向单个计算机添加多个 NIC 可能不会显着提高您的吞吐量。
规范中列出的理论最大吞吐量在现实世界中很少能实现。在尝试估算系统中需要的硬件数量时,知道如何查找和基准测试瓶颈的优秀工程师价值连城。在您购买庞大的系统之前,请构建一个较小的原型,并花一些时间找出瓶颈在哪里。您对系统进行分析的越好,您就越能有效地调整系统以满足您的成本要求。
尽管您为流媒体选择的硬件与任何 LAN 或 WAN 数据传输所需的硬件类似,但软件决定了硬件的使用效率,并最终决定了您应该购买哪些硬件。Apple 提供了其流媒体服务器的开源版本,称为 DARWIN 流媒体服务器。它需要执行 Apple 公共源代码许可(请参阅资源)。DARWIN 流媒体服务器可以流式传输 Apple 专有的“QuickTime Hinted”文件,但由于服务器是开源的,因此它很可能可以被修改以支持其他文件格式。
QuickTime 目前在 Linux 下的客户端端不受支持。Lucent Technologies 最近宣布免费提供其用于 Linux 的 OptiMedia MediaServe 流媒体服务器应用程序(请参阅资源)。他们声称使用行业标准实时流协议 (RTSP),并支持各种文件格式,这应使服务器在许多客户端平台上都很有用。
我审查过的所有其他流媒体服务器都是闭源的。有些,如 Entera 和 RealNetworks,在 Linux 上运行(请参阅资源)。Entera 的 TeraCAST 和 TeraEDGE 流媒体服务器结合 RTSP 使用开放标准 RTP/RTCP 流协议。RealNetworks 拥有自己的专有 RDP 协议,他们将其与 RTSP 一起使用以与 RealPlayer 客户端通信。相比之下,Microsoft 的专有技术尚未(?)移植到 Linux。
让我们回顾一些通常被轻率地提及为首字母缩略词的基本流媒体技术。它们是什么?它们是如何相互作用的?最终目标是向您介绍 QoS,QoS 是指互联网术语,它指的是性能、可靠性和对任何实时要求的遵守以及可能影响源和目的地之间通信的任何其他互联网服务方面。许多商业流媒体产品都通过其 QoS 功能在市场上脱颖而出。小心。您将面临许多关于硬件和软件购买的决策,这些决策基于您想要为预期受众提供的 QoS 级别,但除非您控制从源到目的地的完整端到端路径,否则您将始终受到路径中性能最差的链接提供的 QoS 的影响。您所能做的就是确保您的路径部分是最好的,并且您的服务器软件可以最佳地利用现有的 QoS 协议。
IP(互联网协议)是互联网上使用的最基本协议。根据 1990 年的 DOD STANDARD INTERNET PROTOCOL,IP 提供了“……将一组位(互联网数据报)从源通过互连的网络系统传递到目的地所需的功能”。所有其他流媒体协议和机制都位于 IP 之上。
UDP(不可靠数据报协议)是在 IP 上发送数据包类型的常用选择,如果数据到达目的地不是至关重要的。这是一种低开销协议,对于 RTP 特别有用。
RTP(实时协议)是一种实时传输协议,它位于 UDP 之上,因为它更关心“让节目继续进行”,而不是坐在那里等待完美的数据。RTP 最初旨在支持多播多媒体会议,但它也可以用于其他应用程序。
另一方面,TCP(传输控制协议)经过工程设计,旨在提供稳健、无错误的数据传输。它与 RTP 在同一级别运行,但用于大多数对时间不敏感的互联网通信或需要高数据可靠性的连接。
RTSP 是一种应用级协议,它使用 RTP 的较低级别元素来管理必须组合在一起才能创建多媒体会话的多个流。这些流可以来自许多来源,甚至地理位置分离的位置。
RTCP(实时控制协议)数据包通过 TCP 连接传输,与 RTP 数据包协同工作,以监视 QoS 并向 RTP 会话的参与者提供反馈,以便他们可以采取任何可能的措施来提高 QoS。
RSVP(资源预留协议)与 QoS 密切相关。RSVP 旨在用作一个单独的进程,允许应用程序请求各种 QoS 级别。沿请求数据路由的节点分析 RSVP 请求,确定请求者是否具有该 QoS 级别的权限以及请求的 QoS 级别是否可用,并报告他们将提供请求的 QoS 或报告错误。
您不需要完全理解这些协议中的任何一个,但您应该知道 RSVP 是一种极其丰富的协议,它为服务器供应商提供了很大的 QoS 改进空间。在您选择流媒体服务器软件之前,询问他们的产品如何处理 QoS 问题(尤其是通过 RSVP 协议)会很有用。
这些功能在客户端计算机上执行,但我将在此处简要提及它们,因为它们可能会影响服务器端系统。由于标准互联网协议的性质,在决定服务器系统时,不应有必要考虑客户端平台。不幸的是,非法垄断的力量可以无视开放标准,并将自己的专有技术强加于市场。随着开源运动的兴起,这种类型的控制将更难维持。如果您计划流式传输封闭的专有数据格式,那么您在服务器端的选择将受到严重限制。您可能需要权衡促进限制竞争的过程的未来价值,然后再做出迫使您走上这条道路的业务决策。
通过 LAN 或 WAN 流式传输多媒体内容的需求为每个可以根据多媒体业务的特定需求量身定制的硬件或软件领域创造了巨大的市场。Streaming Media, Inc. 是该行业信息的良好来源,他们自称为“流媒体行业的家园”。对行业产品进行几周的探索可以为您节省无数小时和美元。
如果您计划使用 Linux,请仔细查看供应商,以确定他们对开源、开放标准、许可的立场,以及他们是否有资格提供必要的深入支持,以指导您度过您即将从这些供应商那里体验到的混乱的兜售。警惕预先包装了您所需一切的“多媒体设备”。除非该软件包包含针对此问题所有方面的完整解决方案,否则您可能会花费大量资金进行设置,因此,用一句老式的军队用语来说,您的数据可以“快点并等待”到客户端的下一个链接。
