Web视听时代来临 HTML 5视频音频元素全解析

【51CTO精选译文】<audio>和<video>是首批被添加到HTML 5规范中的特征标记。它们的加入使得浏览器能够以一种更易用的方式来处理音频及视频文件。

51CTO编辑推荐：HTML 5 下一代Web开发标准详解

本文作者Kurt Cagle是一位资深的多媒体应用开发者，对HTML 5规范十分关注。本文对HTML 5规范中最吸引人的<audio>和<video>功能进行了最详细的介绍。以下是Kurt文章的全文翻译。对HTML 5其他规范感兴趣的读者们，可以参考51CTO之前对HTML 5标准的全面介绍，或者也可以在HTML 5专题中寻找自己感兴趣的内容。

多年以前，当我还是程序员时，我所做的大量工作主要集中在为图形显示及电脑游戏开发多媒体应用程序（这些应用程序结合了视频、音频、动画和文字）方面。在90年代初，我主要使用的工具是Macromedia Director。在业内，一直存在基于web的音频（更不用说视频）应用程序开发的想法，直到Realnetworks的出现。RealNetworks是首次提供了较大规模的流媒体技术，从而使得开发人员可以通过Internet发送缓冲的媒体内容。后来，RealNetworks又允许将播放文件嵌入到网页之中。 

从技术角度来讲，对HTML中指定的视频和音频进行标记的想法在HTML 3（甚至HTML 4）上实现起来的难度很大。因为HTML 4本质上是个“静止”版本，用于显示内容的特定机制十分依赖相应的格式（例如，苹果公司的QuickTime电影和Flash视频），并且通常需要将标记与各个参数进行捆绑后再向服务器传递相关信息。因此，将视频及音频嵌入到网页的工作变成了一种特殊的技能。

因此，将<audio>及<video>作为首批被添加到HTML 5规范中的特征标记也就变得理所当然了，而这似乎已经成为浏览器厂商实现HTML 5的首要考虑的事情。这些新加入的元素使得浏览器能够以一种易于使用的方式处理音频及视频文件，而HTML 5所提供的API还能带给用户许多帮助，从而更精确的对视频和音频进行控制。

#p#

HTML 5 的<audio>和<video>元素

在<audio>和<video>中，<audio>较为简单，表1中列出了<audio>的所有属性

表1 <audio>元素属性

注意，<audio>元素(及<video>元素)同样支持所有基于<div>的其他常规属性（如style、class等），甚至在该接口不可见时也是如此。

<video>元素除包含<audio>中所有属性外，还有额外三种属性。

表2 < Video >元素属性

当视频处于缓冲状态时，Poster实际上是一个图像占位符，它并不总是必需的。当预载入视频时，许多视频编解码器会自动从视频中解压一个特殊的图片来作为poster。当然，并不是所有的编解码器（codec）都有这一功能。

当视频载入时，在特定环境下使用指定poster（放弃视频所提供的默认poster）来做为某个视频的“商标”是非常有帮助的。当视频开始播放或是暂停时，poster所显示的图片与内容是不相干的。在另一种情况中，解码器可以显示视频暂停前的最后一张图片，或者当视频持续播放时，视频的最后一帧图片将会显示出来。

通常情况下，视频和音频的播放会采用指定媒体源所压缩到媒体中的编解码器，但有时浏览器并不支持某种特殊的的编解码器。在这种情况下，可以使用@src属性作为解决方案，HTML5同时定义了第二个<source>元素，它主要的作用是定义媒体源所在的位置及媒体源播放所使用的编解码器类型。表3 列出了<source>元素的定义

表3 <Source>元素属性

在多<source>元素存在的情况下，如果web浏览器不能使用第一个指定编解码器（浏览器不支持），它将会搜寻列表直到发现第一个可以使用的编解码器为止。

HTML 5代码后面所紧跟的比特描述了视频元素所支持的三种不同编解码器：

第一种情况是：如果<source>元素描述的是mp4资源（最典型的视频类型为MPEG格式，尽管它们经常是“mpg”格式的直接扩展），那么它将使用baseline profile 编解码器。第二种情况是将视频与simple profile视频编解码器一起编码，第三种情况是将视频与Ogg-vorbis编解码器一同编码。最典型的做法是，让@type属性包含关联的隐藏属性。如果它没有包含，那么@media属性可以通过@type信息来确定。注意，你在判断@src属性时可以有多种选择：即使<source>元素存在，它也会被提前使用，但你必须在你的媒体元素中选择一个。（51CTO编辑注：HTML 5标准确立的最大的争议点就是有关视频元素所支持的编解码器的问题。比如Mozilla坚持将开放的Ogg标准加入进来，而苹果则争抢着把MP4标准加入，其他公司也抱着相同的想法。这就造成了上述描写的情况。）

理论上，<video>和<audio>元素必须可以包含当前可以使用的绝大多数编解码器。但在实际过程中，当前支持<video>和<audio>元素的浏览器其实只支持开源的Ogg Vorbis 和Theora标准。你可能并不熟悉这些标准——尽管Terry Pratchett的《磁盘世界》（Diskworld）系列丛书的粉丝们也许可以从Exquisitor Vorbis（“small gods”）的特性中找到Ogg Vorbis的名字，并且（也很有可能）在他的书中多次提到 Nanny Ogg的特性。另一方面，Theora (Jones)是Max Headroom 属性调节器（controller）的名称。

与更为人熟知的MPEG格式相比，Ogg Vorbis标准是开源并且资料非常详实。因此，在为游戏及在线应用程序存储音频文件时，Ogg Vorbis格式非常受欢迎。与其他格式相比，Ogg Vorbis/Theora 并没有得到HTML 5规范所给予的更多优惠，但它是Firefox唯一支持的格式。

Chrome 和 Safari 团队均宣布有可能将两种标准都添加进来的打算。

#p#

音频，视频以及DOM

<video>及<audio>元素均使用基于抽象HTMLMediaElement （注：不包含正规<media>元素）的相同DOM接口。你可以在页面中使用这些接口来控制各种视频及音频流。例1显示了这些接口的交互式数据语言（IDL）。

从IDL中可以看出，媒体元素的API主要完成以下工作：

Src属性负责设置媒体的@src属性，但src属性的改变并不能自动改变当前视频的属性。当你改变src后，你需要调用load()函数来对新视频及其属性进行重新载入，并在视频完成载入和缓冲后调用play()。在一个纯粹的并行网络世界中，完成这个工作相对容易。当你从一个正在运行的web页面上下载媒体到本地文件时，这些代码已经开始运行了。

然而，媒体文件在本质上是一个需要较长时间的过程。当你需要同时完成载入、缓冲音频及视频文件及网络连接时，这将是一个巨大的挑战，因为这会受到很多因素的影响。由于这个原因，当我们在处理web上的音频及视频时，如果你想对该过程进行控制的话，那你就不得不采取异步工作的方式，将客户端在媒体服务器中获得的各种信息进行重新处理。表4（直接提取于HTML5文档）提供了一个各种事件以及在它们被调度时的完整信息。

表4：媒体用户接口事件

在表4的所有事件中，事件canplay 和 canplaythrough是最有用的。首先，当足够的数据被视频播放器载入并开始播放时，canplay将会被使用（即便所有数据并未完全载入）。对于事件canplaythrough来说,它会在数据完全载入到浏览器缓冲区之后才会运行，这样使得视频可以流畅播放，无需因等待缺失数据而暂停。

当视频文件已经有足够的数据可以开始播放时，它将产生oncanplay事件，该事件可以点亮Play按钮。也就是说，当用户按下Play按钮时，它实际上已经在播放刚刚下载完成的视频了。

#t#但这些仅仅在理论上是可行的。实际上，即使在firefox中，<video>和<audio>也没有完全实现。由于这个原因，很多事件的处理并没有传递到JaveScript层。这就意味着，由于这一操作很粗略，先调用load()再调用play()仍然是载入视频源的最好方式。这一领域很有可能在执行过程中（按照XHTML的标准）得到更充分的支持。

浏览器供应商的情有独钟

一切迹象表明，浏览器供应商们把HTML 5标准中对多媒体方面的支持看成是重中之重（51CTO编辑推荐阅读：HTML 5与浏览器们不得不说的故事）。由于HTML 5可以支持多种媒体格式，并能够更加有效在WEB浏览器中播放音频和视频，出现这种情况是自然而然的。然而，在HTML 5对多媒体的支持普及之前，浏览器对这些技术标准的实现还有很长的路要走。

【51CTO.com译稿，非经授权请勿转载。合作站点转载请注明原文译者和出处为51CTO.com，且不得修改原文内容。】

原文：Exploring HTML 5's Audio/Video Multimedia Support   作者：Kurt Cagle