知识产权与互联网/流媒体

流媒体是不断由流媒体提供商提供并呈现在最终用户面前的多媒体。使用流媒体，客户端浏览器或插件可以在整个文件传输完成之前开始显示数据。 该名称指的是媒体的交付方式，而不是媒体本身。这种区别通常应用于通过电信网络分发的媒体，因为大多数其他交付系统要么天生就是流媒体（例如，广播、电视），要么天生就不是流媒体（例如，书籍、录像带、音频 CD）。动词“流”也源于此术语，意思是通过这种方式交付媒体。互联网电视是一种常见的流媒体。流媒体可以是视频和音频之外的其他内容。实时闭幕字幕和股票代码被认为是流媒体文本，实时文本也是如此。

实时流媒体，通过互联网进行实时交付，涉及一个媒体摄像头，一个编码器来数字化内容，一个媒体发布者，以及一个内容分发网络来分发和交付内容。

历史

在 20 世纪中叶计算的早期，人们就尝试在计算机上显示媒体。然而，在几十年的时间里，几乎没有取得进展，这主要归因于计算机硬件的高成本和有限的能力。

从 20 世纪 80 年代后期到 90 年代，消费级个人计算机变得足够强大，可以显示各种媒体。与流媒体相关的首要技术问题是

• 具有足够的CPU 能力和总线带宽来支持所需的数据速率
• 在操作系统 (OS) 中创建低延迟中断路径，以防止缓冲区下溢。

然而，计算机网络仍然有限，媒体通常通过非流媒体渠道交付，例如从远程服务器下载数字文件，然后将其保存到最终用户计算机上的本地驱动器，或者将其存储为数字文件并从CD-ROM中播放。

在 20 世纪 90 年代后期和 21 世纪初，互联网用户看到了

• 更大的网络带宽，尤其是在最后一英里
• 更多网络访问权限，尤其是互联网
• 使用标准协议和格式，例如TCP/IP、HTTP 和HTML
• 互联网的商业化。

严重轮胎损坏是第一个在互联网上进行现场演出的乐队。1993 年 6 月 24 日，该乐队在施乐 PARC 举行了一场演出，而大楼的其他地方，科学家们正在讨论新的技术（Mbone），用于使用多播在互联网上广播。作为其技术的证明，该乐队被广播，并且可以在澳大利亚和其他地方被实时观看。

RealNetworks也是流媒体市场的先驱，他们在 1995 年通过互联网广播了早期音频活动之一 - 扬基队与西雅图水手队的棒球比赛。 他们在 1997 年推出了第一款流媒体视频技术，即RealPlayer。

当Word 杂志在 1995 年推出时，他们在互联网上推出了第一个流媒体配乐。他们使用当地的市中心音乐家，第一个音乐流是 Karthik Swaminathan 的“大轮子”，第二个是 Karthik Swaminathan 与Marc Ribot和 Christine Bard 合作的“当我们贫穷时”。

不久之后，在 1996 年初，微软开发了一种名为ActiveMovie的媒体播放器，该播放器允许流媒体，并包含专有的流媒体格式，它是后来在 1999 年的Windows Media Player 6.4 中的流媒体功能的继任者。

1999 年 6 月，苹果还在其Quicktime 4 应用程序中引入了一种流媒体格式。它后来也被广泛应用于网站，以及 RealPlayer 和 Windows Media 流媒体格式。网站上的竞争格式要求每个用户下载相应的应用程序以进行流媒体播放，导致许多用户不得不将其计算机上安装所有这三种应用程序以确保通用兼容性。

大约在 2002 年，人们对单一、统一的流媒体格式的兴趣以及Adobe Flash在计算机上的广泛应用，促使人们通过 Flash 开发了一种视频流媒体格式，这是如今许多流行的视频托管网站（例如YouTube）中使用基于 Flash 的播放器中的格式。

不断增长的用户对实时流媒体的需求促使 YouTube 为用户实施了其新的实时流媒体服务。

计算机网络的这些进步，加上功能强大的家用电脑和现代操作系统，使流媒体对普通消费者来说既实用又经济实惠。独立的互联网广播设备出现，为听众提供无需计算机即可收听音频流的选择。

一般来说，多媒体内容的体积很大，因此媒体存储和传输成本仍然很高。为了在一定程度上抵消这一点，媒体通常会被压缩，用于存储和流媒体。

不断增长的用户对高清 (HD) 内容在家庭中不同设备上的流媒体需求，促使业界开发了一系列技术，例如无线高清或ITU-TG.hn，它们针对流媒体高清内容进行了优化，无需用户安装新的网络电缆。

如今，媒体流可以进行实时流媒体或点播流媒体。实时流媒体通常通过一种称为真流媒体的方式提供。真流媒体直接将信息发送到计算机或设备，而不会将其保存到硬盘。点播流媒体通过一种称为渐进式流媒体或渐进式下载的方式提供。渐进式流媒体将文件保存到硬盘，然后从该位置播放。点播流媒体通常会保存到硬盘和服务器，供较长的时间使用；而实时流媒体仅在特定时间可用（例如，在足球比赛期间）。

随着平板电脑和智能手机等移动设备的普及，这些设备都依赖电池续航，数字媒体流的发展如今集中在不依赖 Adobe Flash 的格式上——Adobe Flash 以其相对较高的计算机资源使用量而闻名，因此会影响移动设备的电池续航时间。

流媒体带宽和存储

例如，要将电影流式传输到 Apple TV、Google TV 或索尼电视蓝光光盘播放器，建议使用 2.5 Mbit/s 或更高的宽带速度，而对于高清内容，则建议使用 10 Mbit/s。

即使是流式传输相同内容，单播连接也需要来自同一个流服务器的多个连接

流媒体存储大小根据以下公式计算流媒体带宽和媒体长度（对于单个用户和文件）：

存储大小（以 兆字节 为单位）= 长度（以秒为单位）× 比特率（以比特/秒为单位）/（8 × 1024 × 1024）

现实世界的例子

以 300 kbit/s 编码的视频（这是 2005 年的典型宽带视频，通常以 320 × 240 像素的窗口大小编码）将是

（3,600 s × 300,000 bit/s）/（8×1024×1024）大约需要 128 MiB 的存储空间。

如果该文件存储在服务器上以供按需流式传输，并且该流同时被 1,000 人使用 单播 协议观看，则要求

300 kbit/s × 1,000 = 300,000 kbit/s = 300 Mbit/s 的带宽

这相当于每小时大约 135 GB。使用 多播 协议，服务器只发送一个对所有用户通用的流。因此，此类流仅使用 300 kbit/s 的服务带宽。有关这些协议的更多信息，请参见下文。

直播的计算方法类似。

假设：编码器的速度为 500 kbit/s。

如果节目持续 3 小时，有 3,000 名观众，则计算结果为

传输的 MiB 数 = 编码器速度（以比特/秒为单位）× 秒数 × 观众数 /（8*1024*1024）

传输的 MiB 数 = 500,000（比特/秒）× 3 × 3,600（= 3 小时）× 3,000（观众数）/（8*1024*1024）= 1,931,190 MiB

编解码器、比特流、传输、控制

音频流使用音频编解码器进行压缩，例如 MP3、Vorbis 或 AAC。

视频流使用视频编解码器进行压缩，例如 H.264 或 VP8。

编码的音频和视频流组装在容器比特流中，例如 FLV、WebM、ASF 或 ISMA。

比特流使用传输协议从流服务器传递到流客户端，例如 MMS 或 RTP。

流客户端可以使用控制协议与流服务器进行交互，例如 MMS 或 RTSP。

协议问题

设计支持流媒体的网络协议会引发许多问题，例如

• 数据报 协议（例如 用户数据报协议 (UDP)）将媒体流发送为一系列小数据包。这很简单且高效；但是，协议中没有机制保证交付。接收应用程序负责检测丢失或损坏并使用 纠错 技术恢复数据。如果数据丢失，流可能会出现 中断。
• 实时流协议 (RTSP)、实时传输协议 (RTP) 和 实时传输控制协议 (RTCP) 是专门为通过网络流式传输媒体而设计的。RTSP 在各种传输协议上运行，而后两者则建立在 UDP 之上。
• 另一种似乎融合了使用标准 Web 协议的优点以及能够用于流式传输实时内容的能力的方法是 HTTP 自适应比特率流。HTTP 自适应比特率流基于 HTTP 渐进式下载，但与之前的方法不同，这里文件非常小，因此可以与数据包流式传输相比，就像使用 RTSP 和 RTP 的情况一样。
• 可靠的协议（例如 传输控制协议 (TCP)）保证媒体流中每个比特的正确传递。但是，它们通过超时和重试系统来实现这一点，这使得它们更难以实施。这也意味着，当网络上发生数据丢失时，媒体流会停止，直到协议处理程序检测到丢失并重新传输丢失的数据。客户端可以通过缓冲数据以供显示来最大程度地减少这种影响。虽然缓冲造成的延迟在视频点播场景中是可以接受的，但如果缓冲带来的延迟超过 200 毫秒，视频会议等交互式应用程序的用户将体验到保真度的下降。
• 单播 协议从服务器向每个接收者发送媒体流的独立副本。单播是大多数互联网连接的标准，但在许多用户想要同时观看同一 电视节目 时，扩展性不佳。

多播将多媒体的同一副本广播到整个网络上的一个客户端组

• 多播 协议的开发是为了减少当多个接收者独立地接收单播内容流时发生的数据复制（以及随之而来的服务器/网络负载）。这些协议从源头向一个接收者组发送一个流。多播传输是否可行取决于网络基础设施和类型。多播的一个潜在缺点是失去了 视频点播 功能。无线电或电视材料的连续流式传输通常会阻止接收者控制播放。但是，缓存服务器、数字 机顶盒 和缓冲的 媒体播放器 等元素可以减轻此问题。
• IP 多播 提供了一种将单个媒体流发送到 计算机网络 上一组接收者的方式。多播协议，通常是 Internet 组管理协议，用于管理将多播流传递到 LAN 上的接收者组。部署 IP 多播的挑战之一是，LAN 之间的路由器和防火墙必须允许通过发送给多播组的数据包。如果提供内容的组织控制着服务器和接收者之间的网络（例如，教育机构、政府机构和企业 内联网），那么可以使用 协议独立多播 等路由协议将流内容传递到多个 局域网 段。
• 点对点 (P2P) 协议安排预先录制好的流在计算机之间发送。这可以防止服务器及其网络连接成为瓶颈。然而，它引发了技术、性能、质量和业务问题。