Web視聽時代來臨 HTML 5視頻音頻元素全解析
原創(chuàng)【51CTO精選譯文】<audio>和<video>是首批被添加到HTML 5規(guī)范中的特征標(biāo)記。它們的加入使得瀏覽器能夠以一種更易用的方式來處理音頻及視頻文件。
51CTO編輯推薦：HTML 5 下一代Web開發(fā)標(biāo)準(zhǔn)詳解
本文作者Kurt Cagle是一位資深的多媒體應(yīng)用開發(fā)者，對HTML 5規(guī)范十分關(guān)注。本文對HTML 5規(guī)范中最吸引人的<audio>和<video>功能進行了最詳細的介紹。以下是Kurt文章的全文翻譯。對HTML 5其他規(guī)范感興趣的讀者們，可以參考51CTO之前對HTML 5標(biāo)準(zhǔn)的全面介紹，或者也可以在HTML 5專題中尋找自己感興趣的內(nèi)容。
多年以前，當(dāng)我還是程序員時，我所做的大量工作主要集中在為圖形顯示及電腦游戲開發(fā)多媒體應(yīng)用程序（這些應(yīng)用程序結(jié)合了視頻、音頻、動畫和文字）方面。在90年代初，我主要使用的工具是Macromedia Director。在業(yè)內(nèi)，一直存在基于web的音頻（更不用說視頻）應(yīng)用程序開發(fā)的想法，直到Realnetworks的出現(xiàn)。RealNetworks是首次提供了較大規(guī)模的流媒體技術(shù)，從而使得開發(fā)人員可以通過Internet發(fā)送緩沖的媒體內(nèi)容。后來，RealNetworks又允許將播放文件嵌入到網(wǎng)頁之中。
從技術(shù)角度來講，對HTML中指定的視頻和音頻進行標(biāo)記的想法在HTML 3（甚至HTML 4）上實現(xiàn)起來的難度很大。因為HTML 4本質(zhì)上是個“靜止”版本，用于顯示內(nèi)容的特定機制十分依賴相應(yīng)的格式（例如，蘋果公司的QuickTime電影和Flash視頻），并且通常需要將標(biāo)記與各個參數(shù)進行捆綁后再向服務(wù)器傳遞相關(guān)信息。因此，將視頻及音頻嵌入到網(wǎng)頁的工作變成了一種特殊的技能。
因此，將<audio>及<video>作為首批被添加到HTML 5規(guī)范中的特征標(biāo)記也就變得理所當(dāng)然了，而這似乎已經(jīng)成為瀏覽器廠商實現(xiàn)HTML 5的首要考慮的事情。這些新加入的元素使得瀏覽器能夠以一種易于使用的方式處理音頻及視頻文件，而HTML 5所提供的API還能帶給用戶許多幫助，從而更精確的對視頻和音頻進行控制。
#p#
HTML 5 的<audio>和<video>元素
在<audio>和<video>中，<audio>較為簡單，表1中列出了<audio>的所有屬性
表1 <audio>元素屬性
|
屬性名稱 |
值的格式 |
描述 |
|
src |
xs:anyURI |
該屬性提供媒體源的URL地址 |
|
autobuffer |
Autobuffer （自動緩沖） |
在網(wǎng)頁顯示時，該二進制屬性表示是由用戶代理（瀏覽器）自動緩沖的內(nèi)容，還是由用戶使用相關(guān)API進行內(nèi)容緩沖 |
|
autoplay |
Autoplay （自動播放） |
在網(wǎng)頁顯示時，該二進制屬性表示當(dāng)網(wǎng)頁完成載入后瀏覽器是否應(yīng)該自動播放視頻 |
|
loop |
Loop（循環(huán)） |
在網(wǎng)頁顯示時，該二進制屬性表示當(dāng)多媒體運行結(jié)束后瀏覽器是否應(yīng)該自動循環(huán)播放 |
|
controls |
Controls （控制） |
在網(wǎng)頁顯示時，該二進制屬性表示用戶代理（瀏覽器）是否允許用戶對視頻進行控制 |
注意，<audio>元素(及<video>元素)同樣支持所有基于<div>的其他常規(guī)屬性（如style、class等），甚至在該接口不可見時也是如此。
<video>元素除包含<audio>中所有屬性外，還有額外三種屬性。
表2 < Video >元素屬性
|
屬性名稱 |
值的格式 |
描述 |
|
src |
xs:anyURI |
該屬性提供媒體源的URL地址 |
|
autobuffer |
Autobuffer（自動緩沖） |
在網(wǎng)頁顯示時，該二進制屬性表示是由用戶代理（瀏覽器）自動緩沖的內(nèi)容，還是由用戶使用相關(guān)API進行內(nèi)容緩沖 |
|
autoplay |
Autoplay（自動播放） |
在網(wǎng)頁顯示時，該二進制屬性表示當(dāng)網(wǎng)頁完成載入后瀏覽器是否應(yīng)該自動播放視頻 |
|
loop |
Loop（循環(huán)） |
在網(wǎng)頁顯示時，該二進制屬性表示當(dāng)多媒體運行結(jié)束后瀏覽器是否應(yīng)該自動循環(huán)播放 |
|
controls |
Controls（控制） |
在網(wǎng)頁顯示時，該二進制屬性表示用戶代理（瀏覽器）是否允許用戶對視頻進行控制 |
|
width |
dimension ###(cm|em|en|in|px|pt|%) |
該屬性表示在合適的地方提供視頻圖像的顯示寬度。當(dāng)高度未指明時，其值將與給定的初始視頻寬度成一定比例 |
|
height |
dimension ###(cm|em|en|in|px|pt|%) |
該屬性表示在合適的地方提供視頻圖像的顯示高度。當(dāng)寬度未指明時，其值將與給定的初始視頻高度成一定比例 |
|
poster |
xs:anyURI |
當(dāng)視頻未響應(yīng)或緩沖不足時，該屬性值鏈接到一個圖像。該圖像將以一定比例被顯示出來 |
當(dāng)視頻處于緩沖狀態(tài)時，Poster實際上是一個圖像占位符，它并不總是必需的。當(dāng)預(yù)載入視頻時，許多視頻編解碼器會自動從視頻中解壓一個特殊的圖片來作為poster。當(dāng)然，并不是所有的編解碼器（codec）都有這一功能。
當(dāng)視頻載入時，在特定環(huán)境下使用指定poster（放棄視頻所提供的默認(rèn)poster）來做為某個視頻的“商標(biāo)”是非常有幫助的。當(dāng)視頻開始播放或是暫停時，poster所顯示的圖片與內(nèi)容是不相干的。在另一種情況中，解碼器可以顯示視頻暫停前的最后一張圖片，或者當(dāng)視頻持續(xù)播放時，視頻的最后一幀圖片將會顯示出來。
通常情況下，視頻和音頻的播放會采用指定媒體源所壓縮到媒體中的編解碼器，但有時瀏覽器并不支持某種特殊的的編解碼器。在這種情況下，可以使用@src屬性作為解決方案，HTML5同時定義了第二個<source>元素，它主要的作用是定義媒體源所在的位置及媒體源播放所使用的編解碼器類型。表3 列出了<source>元素的定義
表3 <Source>元素屬性
|
屬性名稱 |
值的格式 |
描述 |
|
src |
xs:anyURI |
該屬性提供媒體源的URL地址 |
|
type |
媒體源的隱藏類型，字符串形式 |
該屬性包含了媒體源的播放隱藏類型，通常出現(xiàn)在視頻格式中 |
|
media |
一個媒體編解碼器的字符串 |
該字符串包含了與指定媒體源所匹配的編解碼器信息 |
在多<source>元素存在的情況下，如果web瀏覽器不能使用第一個指定編解碼器（瀏覽器不支持），它將會搜尋列表直到發(fā)現(xiàn)第一個可以使用的編解碼器為止。
HTML 5代碼后面所緊跟的比特描述了視頻元素所支持的三種不同編解碼器：
第一種情況是：如果<source>元素描述的是mp4資源（最典型的視頻類型為MPEG格式，盡管它們經(jīng)常是“mpg”格式的直接擴展），那么它將使用baseline profile 編解碼器。第二種情況是將視頻與simple profile視頻編解碼器一起編碼，第三種情況是將視頻與Ogg-vorbis編解碼器一同編碼。最典型的做法是，讓@type屬性包含關(guān)聯(lián)的隱藏屬性。如果它沒有包含，那么@media屬性可以通過@type信息來確定。注意，你在判斷@src屬性時可以有多種選擇：即使<source>元素存在，它也會被提前使用，但你必須在你的媒體元素中選擇一個。（51CTO編輯注：HTML 5標(biāo)準(zhǔn)確立的最大的爭議點就是有關(guān)視頻元素所支持的編解碼器的問題。比如Mozilla堅持將開放的Ogg標(biāo)準(zhǔn)加入進來，而蘋果則爭搶著把MP4標(biāo)準(zhǔn)加入，其他公司也抱著相同的想法。這就造成了上述描寫的情況。）
理論上，<video>和<audio>元素必須可以包含當(dāng)前可以使用的絕大多數(shù)編解碼器。但在實際過程中，當(dāng)前支持<video>和<audio>元素的瀏覽器其實只支持開源的Ogg Vorbis 和Theora標(biāo)準(zhǔn)。你可能并不熟悉這些標(biāo)準(zhǔn)——盡管Terry Pratchett的《磁盤世界》（Diskworld）系列叢書的粉絲們也許可以從Exquisitor Vorbis（“small gods”）的特性中找到Ogg Vorbis的名字，并且（也很有可能）在他的書中多次提到 Nanny Ogg的特性。另一方面，Theora (Jones)是Max Headroom 屬性調(diào)節(jié)器（controller）的名稱。
與更為人熟知的MPEG格式相比，Ogg Vorbis標(biāo)準(zhǔn)是開源并且資料非常詳實。因此，在為游戲及在線應(yīng)用程序存儲音頻文件時，Ogg Vorbis格式非常受歡迎。與其他格式相比，Ogg Vorbis/Theora 并沒有得到HTML 5規(guī)范所給予的更多優(yōu)惠，但它是Firefox唯一支持的格式。
Chrome 和 Safari 團隊均宣布有可能將兩種標(biāo)準(zhǔn)都添加進來的打算。
#p#
音頻，視頻以及DOM
<video>及<audio>元素均使用基于抽象HTMLMediaElement （注：不包含正規(guī)<media>元素）的相同DOM接口。你可以在頁面中使用這些接口來控制各種視頻及音頻流。例1顯示了這些接口的交互式數(shù)據(jù)語言（IDL）。
從IDL中可以看出，媒體元素的API主要完成以下工作：
Src屬性負(fù)責(zé)設(shè)置媒體的@src屬性，但src屬性的改變并不能自動改變當(dāng)前視頻的屬性。當(dāng)你改變src后，你需要調(diào)用load()函數(shù)來對新視頻及其屬性進行重新載入，并在視頻完成載入和緩沖后調(diào)用play()。在一個純粹的并行網(wǎng)絡(luò)世界中，完成這個工作相對容易。當(dāng)你從一個正在運行的web頁面上下載媒體到本地文件時，這些代碼已經(jīng)開始運行了。
然而，媒體文件在本質(zhì)上是一個需要較長時間的過程。當(dāng)你需要同時完成載入、緩沖音頻及視頻文件及網(wǎng)絡(luò)連接時，這將是一個巨大的挑戰(zhàn)，因為這會受到很多因素的影響。由于這個原因，當(dāng)我們在處理web上的音頻及視頻時，如果你想對該過程進行控制的話，那你就不得不采取異步工作的方式，將客戶端在媒體服務(wù)器中獲得的各種信息進行重新處理。表4（直接提取于HTML5文檔）提供了一個各種事件以及在它們被調(diào)度時的完整信息。
表4：媒體用戶接口事件
|
事件名稱 |
接口 |
在什么時將被調(diào)度 |
前提條件 |
|
Loadstart 加載開始 |
Event 事件 |
瀏覽器開始尋找媒體數(shù)據(jù)，作為資源選擇算法的一部分 |
NETWORK_LOADING 網(wǎng)絡(luò)狀態(tài)為裝載狀態(tài) |
|
Progress 進度 |
Event 事件 |
瀏覽器獲取媒體數(shù)據(jù)。 |
NETWORK_LOADING 網(wǎng)絡(luò)狀態(tài)為裝載狀態(tài) |
|
Suspend 掛起 |
Event 事件 |
瀏覽器有意不在當(dāng)前獲取媒體數(shù)據(jù)，但是也不全部下載媒體資源 |
NETWORK_IDLE 網(wǎng)絡(luò)狀態(tài)為空閑狀態(tài) |
|
Abort 終止 |
Event 事件 |
在媒體數(shù)據(jù)完全下載完之前，瀏覽器停止獲得媒體數(shù)據(jù)。這不能歸因于一個錯誤的發(fā)生 |
錯誤是一個對象，表示媒體錯誤終止的MEDIA_ERR_ABORTED代碼。此時，網(wǎng)絡(luò)是處于空載狀態(tài)，還是處于空閑狀態(tài)，取決于什么時候下載終止 |
|
Error 錯誤 |
Event 事件 |
當(dāng)取得數(shù)據(jù)時，錯誤發(fā)生。 |
錯誤是一個對象，表示媒體錯誤終止的MEDIA_ERR_NETWORK代碼或更高層次的代碼。此時，網(wǎng)絡(luò)是處于空載狀態(tài)，還是處于空閑狀態(tài)，取決于什么時候下載終止 |
|
Emptied 空閑 |
Event 事件 |
先前網(wǎng)絡(luò)狀態(tài)不是處于空載狀態(tài)的媒體要素剛剛轉(zhuǎn)向了這種狀態(tài)（或者是因為當(dāng)下載時被報告了一個致命的錯誤，或者是因為當(dāng)資源選擇算法已經(jīng)運行時，load()方法被調(diào)用，這種情況下它是與load()方法的調(diào)用同時發(fā)生的） |
網(wǎng)絡(luò)狀態(tài)為空載狀態(tài)，所有的IDL屬性都是初始化狀態(tài) |
|
Stalled 遲延 |
Event 事件 |
瀏覽器正在獲取數(shù)據(jù)，但是數(shù)據(jù)出乎意料的沒有到來 |
NETWORK_LOADING. 網(wǎng)絡(luò)狀態(tài)為裝載狀態(tài) |
|
Play 播放 |
Event 事件 |
重新播放已經(jīng)開始。當(dāng)play()方法返回后，接著播放 |
暫停是最近的為假 |
|
Pause 暫停 |
Event 事件 |
重新播放已經(jīng)被停止。當(dāng)pause方法返回后，接著播放 |
暫停是最近的為真 |
|
Loadedmetadata 裝載媒體數(shù)據(jù) |
Event 事件 |
瀏覽器決定媒體資源的持續(xù)時間和尺度。 |
準(zhǔn)備狀態(tài)最近處于擁有當(dāng)前的數(shù)據(jù)或第一次大于所需的數(shù)據(jù)的狀態(tài) |
|
Loadeddata 裝載數(shù)據(jù) |
Event 事件 |
瀏覽器能夠歸還數(shù)據(jù)當(dāng)?shù)谝淮翁幱诋?dāng)前重播的位置 |
準(zhǔn)備狀態(tài)最近提升到擁有的數(shù)據(jù)或第一次大于所需的數(shù)據(jù)的狀態(tài) |
|
Waiting 等待 |
Event 事件 |
因為下一個幀不能得到，所以重新播放被停止，但是瀏覽器希望這個架構(gòu)在這個過程中能被得到 |
準(zhǔn)備狀態(tài)最近等于或少于當(dāng)前的數(shù)據(jù)，暫停則為假。要么搜索為真，要么當(dāng)前回放位置不包含在緩沖的數(shù)據(jù)中。 |
|
Playing 正在播放 |
Event 事件 |
回放被啟動 |
準(zhǔn)備狀態(tài)最近等于或多于未來的數(shù)據(jù)，暫停則為假，搜索則為假；要么當(dāng)前回放位置包含在緩沖的數(shù)據(jù)中。 |
|
Canplay 能夠播放 |
Event 事件 |
瀏覽器能夠繼續(xù)回放媒體數(shù)據(jù)，但如果回放操作現(xiàn)在就開始的話，不用停下來等待進一步的緩沖，媒體資源則不能以當(dāng)前的回放速率一直工作到結(jié)束 |
準(zhǔn)備狀態(tài)最近增加到未來的數(shù)據(jù)或更多 |
|
Canplaythrough 能夠從頭到尾的播放 |
Event 事件 |
瀏覽器如果現(xiàn)在就開始回放操作的話，媒體資源能以當(dāng)前的回放速率一直工作，而不用停下來等待進一步的緩沖 |
準(zhǔn)備狀態(tài)最近等于足夠的數(shù)據(jù) |
|
Seeking 正在尋找 |
Event 事件 |
尋找IDL的屬性被修改為真，搜索操作用去的時間很長。 |
|
|
Seeked 尋找 |
Event 事件 |
尋找IDL的屬性被修改為假 |
|
|
Timeupdate 時間更新 |
Event 事件 |
作為正?；胤诺囊徊糠?，當(dāng)前回放位置被改變；或是以一種有趣的方式進行回放，如間斷進行 |
|
|
Ended 結(jié)束 |
Event 事件 |
因為到達了媒體資源的終點，所以回放被停止 |
當(dāng)前的時間等同于媒體資源結(jié)束的時間；結(jié)束為真。 |
|
Ratechange 交換率 |
Event 事件 |
defaultPlaybackRate或是playbackRate屬性已被更新。 |
|
|
Durationchange 持續(xù)期的交換 |
Event 事件 |
duration屬性已被更新 |
|
|
Volumechange 卷交換 |
Event 事件 |
volume屬性或是muted屬性被修改。在相關(guān)屬性的安裝已經(jīng)返回后，開始工作 |
|
在表4的所有事件中，事件canplay 和 canplaythrough是最有用的。首先，當(dāng)足夠的數(shù)據(jù)被視頻播放器載入并開始播放時，canplay將會被使用（即便所有數(shù)據(jù)并未完全載入）。對于事件canplaythrough來說,它會在數(shù)據(jù)完全載入到瀏覽器緩沖區(qū)之后才會運行，這樣使得視頻可以流暢播放，無需因等待缺失數(shù)據(jù)而暫停。
當(dāng)視頻文件已經(jīng)有足夠的數(shù)據(jù)可以開始播放時，它將產(chǎn)生oncanplay事件，該事件可以點亮Play按鈕。也就是說，當(dāng)用戶按下Play按鈕時，它實際上已經(jīng)在播放剛剛下載完成的視頻了。
#t#但這些僅僅在理論上是可行的。實際上，即使在firefox中，<video>和<audio>也沒有完全實現(xiàn)。由于這個原因，很多事件的處理并沒有傳遞到JaveScript層。這就意味著，由于這一操作很粗略，先調(diào)用load()再調(diào)用play()仍然是載入視頻源的最好方式。這一領(lǐng)域很有可能在執(zhí)行過程中（按照XHTML的標(biāo)準(zhǔn)）得到更充分的支持。
瀏覽器供應(yīng)商的情有獨鐘
一切跡象表明，瀏覽器供應(yīng)商們把HTML 5標(biāo)準(zhǔn)中對多媒體方面的支持看成是重中之重（51CTO編輯推薦閱讀：HTML 5與瀏覽器們不得不說的故事）。由于HTML 5可以支持多種媒體格式，并能夠更加有效在WEB瀏覽器中播放音頻和視頻，出現(xiàn)這種情況是自然而然的。然而，在HTML 5對多媒體的支持普及之前，瀏覽器對這些技術(shù)標(biāo)準(zhǔn)的實現(xiàn)還有很長的路要走。
【51CTO.com譯稿，非經(jīng)授權(quán)請勿轉(zhuǎn)載。合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com，且不得修改原文內(nèi)容。】
原文：Exploring HTML 5's Audio/Video Multimedia Support 作者：Kurt Cagle
