【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