柠檬铺

HTML5 video的世界里，将来会发生什么？Opera公司的Bruce Lawson为您揭示那些即将上架的新鲜货，并指导您如何把这些新特性应用到您的站点上。

 
这篇文章最早是在.net杂志的issue 224上刊登
HTML5把本地多媒体引入到浏览器中。在过去，音视频需要通过第三方插件来处理（这样引发的问题是：并不是所有操作系统或者设备都能使用）流览器与插件之间的通信被局限住了，而且多媒体就像一个黑盒子。
HTML5出现之后，所有主流浏览器都可以支持本地音视频了（包括IE浏览器），虽然这个过程需要让您的媒体文件进行双份的编码（因为IE 和Safari只支持Royalty-encumbered标准的编码）。有了HTML5，突然之间，video可以跟CSS一起排样式了：您可以用半透 明的视频相互覆盖，设置边界与背景图片，旋转盘旋等变换，以及其他各种精彩的变形应用。
如果您看过这篇作者与Vadim Makeev一起写过的文章，您将也会知道音视频拥有简单的API使您可以用JavaScript来控制播放。根据需求的简单或复杂，您可以使用一些简单的JavaScript和CSS做出自己的媒体播放器。
 
我们现在发展到什么程度了？
现在本地的多媒体已经看起来十分炫酷了，当然也不是足够的成熟，毕竟使用浏览器作为媒体播放器也不过两年时间。与此相对应的桌面媒体播放器程序已经存在了15年，在这么多年的锤炼中不断完善。
很多人注意到了，大多数浏览器在播放音频的时候有少许的延迟。许多游戏开发者经常说，FLASH技术残留下来就是为他们提供声音的，正如许多浏览器可以需要两秒钟来加载HTML5音频文件。Patrick Lauke写了一篇文档《Hacking a looping audio that doesn’t have a small delay before looping》

Remy Sharp在文章中描述了一种他称为Audio Sprites的技术来克服iOS的缺陷。而在iOS领域另外两篇必读的文献是HTML5 Video Issues on the iPad and How to Solve them和Unsolved HTML5 video issues on iOS
当然，这些是一些实现细节，而不是规范文档的问题，所以随着平台的逐步发展成熟，这些问题将会逐渐消失的。
所以，目前的情况就是这样了，让我们看看将来会发生一些什么。
 
多媒体的字幕和标题问题
随着网络的发展，web的内容越来越多的是用音视频的形式来体现了，考虑一下有些用户无法听到音轨，或者其母语并不是英语的情况，抑或用户希望用他们自己的语言来阅读字幕和内容的时候。
在你的标题和子标题附近很快就会出现了，通过HTML5<track>元素，可以基于时间轴对媒体文件同步字幕。这个强有力的元素是<video>或者<audio>元素的子类，并指向一个副标题文件。让我们来看看它的一些属性吧：
<track src=subtitles.vtt kind=subtitles srclang=en label=”English”>
Src属性指向了外部的基于时间的文本track，这种属性可以告诉浏览器是否存在subtitle属性（这种对话，需要事先转录或者翻译好否则不 易理解），Caption属性（对话的翻译，声音效果，音乐提示等相关音频信息，特别适合有些时候声音不清晰的情况），Description属性（对媒 体资源视频组件的文字画描述，目的是当视觉组件不好用的时候音频同步方便，例如没有屏幕的应用场景，或者用户视力有障碍），以及Chapter属性和 Metadata属性。默认设置是Subtitle。
Srclang属性告诉浏览器文本文件是什么语言，并且能帮助您与多个音视频集进行关联：这样您就可以提供很多中语言的副标题了。Lable属性是可选的，是一个为track提供的用户可读的标题。

1. <video controls>

2.  <source src=movie.mp4 type=video/mp4>

3.  <source src=movie.webm type=video/webm>

4.  <track type=subtitles srclang=en src=subtitles-en.vtt>

5.  <track type=subtitles srclang=de src=subtitles-de.vtt label=”German”>

6.    <!– fall back content, eg a Flash movie or YouTube embed code

7. </video>

在规范文档中并没有对浏览器如何与基于时间的文本文件通信上作出要求，也没有说明浏览器该如何支持它，但是我们可以用Polyfill进行实验。
为了使用快速原型方法，作者喜欢使用Playr，一个由JulienVilletorte编写的轻量级的脚本，可以从Github上面获得。您只需要抓些图片来装扮Playr UI，加入playr.js和Playr.css在您的页面的Head里面，把类名playr_video加入你的Video tag里面，然后你的页面就会被漂亮的Playr的皮肤补偿了，还拥有在副标题中选择的功能。

需要注意的是，UI是用Polyfill做的，目前还没有被嵌入任何浏览器（但将来会的），Opera，微软和谷歌对它都有贡献；而且很有可能其他浏览器会提供类似的UI和功能。
<track>元素并没有为基于时间轴的文本指定什么特定的格式。在这样的情况下，它是一个webVTT文件，但 是<track>像<img><video><audio>一样一样是格式不可知的。所有浏览器都将支 持新版本的webVTT格式，微软已经声称还将支持一种比较老的叫做TTML的格式。
 
webVTT
webVTT是一个全新的基于时间的文本格式。网页上已经充斥着最少五十种其他格式了，那么为什么还要引入一个新的格式呢？因为大家需要一种简单的格式来完成诸多强大的功能。
作者认为webVTT十分的简单，这一点很重要：如果太难了，作者就不愿意理睬了；而且如果没有副标题的视频存在，也就没有浏览器会支持新的元素和API来让多媒体内容访问了。简单地来描述，WebVTT的代码看起来就是这样的：
WEBVTT
00:01.000 –> 00:02.000 
Hello
00:03.000 –> 00:05.000
World
这是一个简单的UTF-8编码的文本文件，需要在顶部指明webVTT，时间被指明为从媒体开始的偏移量。所以HELLO会在视频开始1秒时出现，持续1秒到2秒时就消失了，副标题也会从开始算三秒后消失，这时WORLD字样就会出现了。
实在是没法再简单了，当然您可以做得更复杂一些，例如您可以改变副标题的位置，像这样：
00:03.000 –> 00:05.000 L:-85%
这样就把副标题的位置提升到85%的位置了，默认位置是视频的底部。
您也可以改变文本的尺寸，例如  S:150% 这样的语句就可以把默认的尺寸放大。另外，也可以让副标题渐渐出现（就像卡拉OK的歌词字幕那样，前面的消失了后面的才会出现）；您也可以定义样式，使得 不同的样式或扬声器的字体颜色各不相同。这方面如果您想了解细节，请访问这个链接看看http://delphiki.com/webvtt/#cue-settings。
比这些样式选项更重要的是拥有一些更加国际化的选项。webVTT规范内嵌了从右到左的显示顺序来支持阿拉伯和希伯来人的阅读习惯，还可以为了中文进行从上到下的显示，还增加了Ruby注释的功能：例如可以为中文，日文，韩文等音标加注释。
如果您也想实验一下webVTT，就用Playr写写试试吧，Opera的Anne van Kesteren写了一个live webVTT validator可以测试你的作品。

全屏视频
大家都喜欢全屏看视频，所以都期待着HTML5规范说明符（虽然在此之前很久都不允许这样）。Webkit实现了自己的JavaScript方法， 名称是WebkitEnterFullscreen() 并且实现了API，只能由用户初始化Action时触发：例如弹出窗口等，除非用户点确认按钮等才可以运行。
在2011年的五月，Webkit宣布它会实现Mozilla自己的特色全屏API， 该API可以允许任何元素全屏（并不仅仅是video了）您或许需要全屏的<canvas>游戏或者视频小工具等通 过<iframe>嵌入页面，脚本还可以让字幕键盘输入在全屏模式下运行，这意味着你可以创造你的超级出色的平台游戏了，通过使用 canvas API它可以全屏运行还有全键盘支持。
Opera也很喜欢这个方法，我们可以看到一些增强互操作性的进展，到那时候，我们将可以通过全窗口的方式来伪实现全屏，设置视频的尺寸来适应窗口的尺寸。
 
同步媒体元素
同步媒体元素的功能仍在被逐步规范中，所以相对于同步标题和副标题而言，距离实现还有有些遥远：将来会允许一些相关的媒体元素（音频，视频或者混合）被链接起来。
同步媒体元素目前有两个主要的用例。您可以想象一下某个站点正在播放体育新闻的视频，是许多视频元素拼接起来的，每个视频都是从不同角度的摄像机捕 获：例如某一个进球的Replay可以从多个角度，追踪球或者球员播放；您也可以想象一个站点正在直播某音乐会，一个镜头给贝斯手，一个镜头给吉他手，一 个镜头拍秘鲁长笛。您移动进度条或者改变播放速率来慢播，对一个视频镜头的操作可以影响其他视频。另一个典型用例是访问性。track元素让我们能够为视 频同步文本字幕，这样的同步功能让我们也可以同步另一个视频或者利用对话的间隙同步某个音轨。
虽然已经拥有了一个完整的API控制器，但是最简单得同步媒体元素的方法还是在video或audio元素上声明并使用mediagroup属性。为mediagroup赋值相同即可完成多个元素的同步了，代码像这样：

•  <video mediagroup=”jedward” src=”bass-guitar.webm”>..</video>

•  <video mediagroup=”jedward” src=”lead-guitar.webm”>..</video>

•  <video mediagroup=”jedward” src=”idiot-1.webm”>..</video>

•  <video mediagroup=”jedward” src=”idiot-2.webm”>..</video>

这样的大块标记可以同步四个摄像机，在Jedward音乐会上分别拍摄不同的音乐家的演出；而下面的同步音频描述方式，在流行的电影Mankini Magic中使用了。

• <video mediagroup=”described-film” 

•    src=”mankini-magic.webm”>..</video>

•  <audio mediagroup=”described-film” src=”describe.ogg”>..</audio>

这种方式依然在被规范的阶段，所以据目前作者所知，还没有什么浏览器支持，也没有polyfill。
 
访问摄像头和麦克风

还有一小部分插件的应用残留了下来，因为HTML5目前还不能完成媒体内容的版权保护，DRM插件就是其中之一。另一个插件是自适应流，可以根据网络情况改变比特率。
针对传统的FLASH插件领域，HTML5现在加入了一些便利的方法来连接用户设备的摄像头和麦克风。就像大家之前知道的 HTML5<device>元素，这个功能现在封装在一个叫做getUserMedia的API中，它可以告诉设备我们希望得到什么格式的媒 体，我们只需要传递audio和video的参数。由于很多设备具有前置摄像头来拍摄用户的画面，还有个后置摄像头，我们需要传递用户标记或者环境。
首先我们进行特征检测：

1.  if(navigator.getUserMedia) {

2.  navigator.getUserMedia(‘audio, video user’, successCallback,

3.  &not; errorCallback);

当我们有了流媒体，我们可以在需要的使用就用上了。在这里，作者只是简单地利用了页面上挂载的流媒体资源的链接。

1. var video = document.getElementsByTagName(&lsquo;video&rsquo;)[0]

2.  …

3.  function successCallback( stream ) {

4.  video.src = stream;

5.  }

一旦有了这个，从canvas元素中拷贝出视频就容易了，使用drawImage来捕获当前视频的帧，然后每隔67毫秒重画一次（大约是每秒15帧）；一旦把它放进了canvas，您就可以通过getImageData来访问像素了。
Opera公司的Richard Tibbett做了一个范例，在canvas中使用JavaScript来进行人脸识别———还是实时的！当发现人脸的时候，还能在相应的位置上画一个魔幻HTML5胡须。
getUserMedia在Opera 12，Opera Mobile12和Chrome金丝雀版本中都支持，大量的范例您可以点击这个链接来查看。【link】
显然，允许网络站点接入您的网络摄像头可能会引发隐私相关的内容，所以用户可以选择式加入，就好像现在的地理位置应用一样。这是一个UI关注的问题，而不是技术方面的问题。
当然，很有可能getUserMedia API的设计者除了画胡须之外有很多别的应用在考虑，例如可以做出基于浏览器的QR/条形码扫描器，或者更准确的说，增强现实。HTML5工作组目前正在 定义一个P2P 的API规范，这个API可以让您把自己的摄像头和麦克风连接到<video>和<audio>元素到其他人的浏览器中，这样做 视频会议都没问题了。
WebRTC
2011年5月，谷歌发布了WebRTC，是一个基于HTML5规范的针对web上面音视频的开源技术。它是一个针对“实时通信”和浏览器中应用视 频会议的RTC标准，可以链接你的摄像头与麦克风到一个web页面与好友进行互动（这个技术是建立在HTML5 PeerConnection API之上的）。
WebRTC使用VP8（WebM中 的视频编解码）和两个音频解码优化来实现会话中的噪声以及回响等的消除，这个叫做iLBC，是一个窄频带声音编解码；此外还有个iSAC，宽频带自适应编 解码器。正如其项目网站上说的那样：“我们很期待看到WebRTC技术将在Firefox，Opera和Chrome中实现！”
正如您所看到的那样，HTML5对于多媒体的支持更加地丰富了。正如我们平时对待HTML5那样，实现方案需要跟上规范定义的改变而与时俱进，规范也需要进一步完成~未来确实让人又兴奋又期待！