HTML 5のマルチメディア（オーディオ／ビデオ）サポート紹介

はじめに

　もう何年も前のこと、プログラマになりたての私が主に携わっていたのは、プレゼンテーションやコンピュータゲームを構築するためのマルチメディアアプリケーション（ビデオ、オーディオ、アニメーション、テキストを組み合わせたプログラム）の開発でした。1990年代初頭には、作業のほとんどをMacromedia Directorで行っていました。ビデオはもちろん、オーディオを扱うWebアプリケーションの開発でさえ夢物語と思われていた頃でしたが、RealNetworksの登場で状況は一変しました。RealNetworksは初めてのメジャーなストリーミングテクノロジであり、バッファにためたメディアコンテンツをインターネット経由で送信するという処理を可能にしました。のちにRealNetworksはWebページへのメディアコンテンツの埋め込みにも対応しました。

　HTML内にビデオやオーディオに関する専用のタグを含めることは、HTML 3では技術的に不可能であり、HTML 4でも非現実的でした。基本的にHTML 4.0は「機能的にフリーズ」されたバージョンなので、コンテンツ表示の仕組みがフォーマット（Apple QuickTimeムービーやFlashビデオなど）にかなり依存しており、サーバに情報を渡すためには、さまざまなパラメータを持つタグを使わなければならないのが普通でした。そのため、Webページへのビデオやオーディオの埋め込みは、混沌とした黒魔術のようなものになっていました。

　こうした状況を考えると、<audio>タグと<video>タグがHTML 5仕様に早々に追加されたのも不思議ではありません。各ブラウザベンダーも、HTML 5仕様のうち、まずこれらの要素を実装しようとしたようです。どちらの要素も、該当するメディアをブラウザが簡単に処理できるようにするためのものです。付随するサポートAPIは、ユーザーによるきめ細かな制御を可能にします。

HTML 5の<audio>および<video>要素

　まずはシンプルな方から見ていきましょう。表1に、<audio>タグの属性を示します。

表1　<audio> 要素の属性

属性名	値の形式	説明
src	xs:anyURI	メディアソースのURLを指定する
autobuffer	autobuffer	このバイナリ属性を指定すると、ユーザーエージェント（ブラウザ）が自動的にコンテンツをバッファリングする。それ以外の場合は、ユーザーが関連APIを介してコンテンツのバッファリングを行う
autoplay	autoplay	このバイナリ属性を指定した場合、ユーザーエージェント（ブラウザ）はページの読み込みが終わると自動的にオーディオの再生を開始する
loop	loop	このバイナリ属性を指定した場合、ユーザーエージェント（ブラウザ）はメディアの終端に達すると最初に戻ってコンテンツの再生を繰り返す
controls	controls	このバイナリ属性を指定すると、ユーザーエージェント（ブラウザ）は処理中のリソースに関してユーザーが対話的操作を行えるコントロールを表示する

　なお、<audio>（および<video>）要素は、インターフェースがたとえ非表示であっても、<div>ベースのすべての要素でサポートされている一般的な属性（id、style、classなど）もサポートします。

　<video>要素には、<audio>要素のすべての属性に加え、さらに3つの属性が含まれています（表2を参照）。

表2　<video>要素の属性

属性名	値の形式	説明
src	xs:anyURI	メディアソースのURLを指定する
autobuffer	autobuffer	このバイナリ属性を指定すると、ユーザーエージェント（ブラウザ）が自動的にコンテンツをバッファリングする。それ以外の場合は、ユーザーが関連APIを介してコンテンツのバッファリングを行う
autoplay	autoplay	このバイナリ属性を指定した場合、ユーザーエージェント（ブラウザ）はページの読み込みが終わると自動的にビデオの再生を開始する
loop	loop	このバイナリ属性を指定した場合、ユーザーエージェント（ブラウザ）はメディアの終端に達すると最初に戻ってコンテンツの再生を繰り返す
controls	controls	このバイナリ属性を指定すると、ユーザーエージェント（ブラウザ）は処理中のリソースに関してユーザーが対話的操作を行えるコントロールを表示する
width	dimension ###(cm\|em\|en\|in\|px\|pt\|%)	この属性には、ビデオ画像の幅を適切な単位で指定する。heightが未指定の場合、その値はwidthが与えられた最初のビデオの高さに応じて決定される
height	dimension ###(cm\|em\|en\|in\|px\|pt\|%)	この属性には、ビデオ画像の高さを適切な単位で指定する。widthが未指定の場合、その値はwidthが与えられた最初のビデオの幅に応じて決定される
poster	xs:anyURI	画像へのリンクを指定する。この画像は、ビデオのレンダリングができない場合、またはバッファリングがまだ済んでいない場合に使用される。このポスター画像は、ビデオの表示位置に指定の縦横比で表示される

　posterは、事実上、ビデオのバッファリング中に使用されるプレースホルダ画像であり、常に必要なものではありません。ビデオコーデックのなかには、ダウンロード前にビデオから特定のフレーム（最初のフレームか、ビデオの途中からランダムに選択されたフレーム）をポスター用に自動抽出し、そのフレームを先に読み込むものがあります。ただし、すべてのコーデックがこの機能を備えているわけではありません。

　このような特別な場合にポスターを使用すると、読み込み中のビデオについて代替の「ブランドマーク」を作成できます。ビデオの再生が実際に始まってしまえば、たとえ一時停止の操作が行われても、ポスター画像は無効になります。一時停止の場合であればその直前のフレームが表示され、ビデオ再生の終了後であれば最後のフレームが表示されます。

　通常、ビデオやオーディオの形式では、そのメディアソースの圧縮およびフォーマットに用いられたコーデックが使用されますが、ブラウザエージェントがそのコーデックをサポートしていないこともあります。こうした場合に備えてHTML 5では、@src属性の代わりとして、予備の<source>要素も定義します。この要素には、与えられたリソースの場所と、そのリソースが公開しているコーデックの種類を指定します。表3に<source>要素の定義を示します。

表3　<source>要素の属性

属性名	値の形式	説明
src	xs:anyURI	メディアソースのURLを指定する
type	リソースのMIMEタイプを示す文字列	この属性には、表示されるメディアリソースのMIMEタイプを（通常は"video/フォーマット"の形式で）指定する
media	メディアのコーデックを示す文字列	この文字列には、指定のリソースに適用可能なコーデックの情報が含まれる

　複数の<source>要素が存在する場合、Webブラウザは、最初のコーデックが（サポート対象外のため）利用できなくても、使えるものが見つかるまでそれらの要素を順に試していきます。

　例えば、次のHTML 5コードでは、1つの<video>要素に3種類のコーデックを指定しています。

<video width="320px" height="240px" autobuffer="autobuffer" autoplay="autoplay">
    <source src='video.mpg' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
    <source src='video.mp4' type='video/mp4; codecs="amp4v.20.8, mp4a.40.2"'>
    <source src='video.ogv' type='video/ogg; codecs="theora, vorbis"'>
</video>

　最初の<source>要素には、mp4リソース（MPEGビデオの最も一般的なタイプで、単に"mpg"拡張子が付けられていることも多い）が記述されています。この場合は、ベースラインプロファイルのビデオコーデックが使用されます。2番目は単純なプロファイルビデオコーデックでエンコードされたビデオ、3番目はOgg-vorbisコーデックでエンコードされたビデオです。ほとんどの場合、@type属性には関連するMIMEタイプが含まれます。そうでない場合は、同様の情報を@media属性によって与えることができます。@src属性に関しては、次のような二者択一的な状況を扱うことになります。この属性はたとえ<source>要素が存在しても優先的に使用されますが、メディア要素内にはどちらか一方が存在しなければなりません。

　建前上は、現在使用されているコーデックのほとんどが<video>および<audio>要素で処理できるはずです。しかし、現在これらの要素に対応しているブラウザでも、実際にサポートされているのはOgg VorbisとTheoraというオープンソースの両規格だけです。どちらも聞き慣れない名前かもしれませんが、Terry Pratchett作のDiscworldシリーズのファンなら、『Small Gods』のキャラクターExquisitor Vorbisと、彼の多くの作品に登場するキャラクターNanny Oggの名前をきっと思い浮かべるでしょう。また、Theora（Jones）は、「Max Headroom」というテレビ番組シリーズに登場するCGキャラクターMax Headroomの誘導員の名前です。

　Ogg Vorbis規格はオープンソースで信頼性が高いという点で、より有名なMPEGフォーマットに匹敵する存在です。そのため、Ogg Vorbisはゲームおよびオンラインアプリケーション向けのオーディオトラックの記録によく利用されます。Ogg Vorbis/Theoraは、HTML 5仕様において他のフォーマットよりも優先されているわけではなく、Firefoxによって（現時点では独占的に）サポートされているフォーマットの1つに過ぎません。これらの規格については、ChromeとSafariの開発チームも、サポート対象のフォーマットとして追加する意向を表明しています。

オーディオとビデオとDOM

　<video>要素と<audio>要素は、どちらも同じDOMインターフェースを使用しており、抽象インターフェースHTMLMediaElementに基づいています（つまり、正式な<media>要素というものは存在しません）。そのため、このインターフェースを使用すれば、さまざまなビデオおよびオーディオストリームをページ内で制御できます。リスト1に、このインターフェースのIDLを示します。

リスト1　HTMLMediaElementインターフェースのIDLコード

interface HTMLMediaElement : HTMLElement { // error state
readonly attribute MediaError error;
// network state
attribute DOMString src;
readonly attribute DOMString currentSrc;
const unsigned short NETWORK_EMPTY = 0;
const unsigned short NETWORK_IDLE = 1;
const unsigned short NETWORK_LOADING = 2;
const unsigned short NETWORK_NO_SOURCE = 3;
readonly attribute unsigned short networkState;
attribute boolean autobuffer;
readonly attribute TimeRanges buffered;
void load();
DOMString canPlayType(in DOMString type);
// ready state
const unsigned short HAVE_NOTHING = 0;
const unsigned short HAVE_METADATA = 1;
const unsigned short HAVE_CURRENT_DATA = 2;
const unsigned short HAVE_FUTURE_DATA = 3;
const unsigned short HAVE_ENOUGH_DATA = 4;
readonly attribute unsigned short readyState;
readonly attribute boolean seeking; // playback state
attribute float currentTime;
readonly attribute float startTime;
readonly attribute float duration;
readonly attribute boolean paused;
attribute float defaultPlaybackRate;
attribute float playbackRate;
readonly attribute TimeRanges played;
readonly attribute TimeRanges seekable;
readonly attribute boolean ended;
attribute boolean autoplay;
attribute boolean loop;
void play();
void pause(); // controls
attribute boolean controls;
attribute float volume;
attribute boolean muted;
};

　IDLの観点から見ると、メディア要素のAPIは次のようなタスクに明確に分類されます。

リソースのネットワーク取得の制御
バッファリングの制御
再生の制御
各種コントロールの属性の設定

　srcプロパティはメディアの@src属性を設定するためのものですが、srcを変更しても現在のビデオが自動的に変更されることはありません。それどころかsrcの変更後は、新しいメディアの要素を読み込むためにload()関数を呼び出し、さらにビデオの読み込みとバッファリングが済んだ時点でplay()を実行する必要があります。完全に同期が取れた世界であれば、こうした面倒な作業も比較的容易に行えます。Webページがローカルで実行されている状況でローカルファイルからメディアを取得する場合は、次のようなコードを書くだけで済みます。

myMedia.src="http://www.mymedia.com/mediasrc.ogg";
myMedia.load();
myMedia.play();

　しかし、メディアというものには本質的に時系列の処理が伴います。オーディオ／ビデオファイルやネットワーク接続について読み込みとキャッシュの両方が必要になれば、それだけで大変な作業が生じます。その難しさは、時間的な処理を必要としないリソースのほとんどを扱う場合には見られないものです。こうした理由から、Web上でのビデオやオーディオの処理を何らかの方法で制御したければ、非同期処理によって、メディア提供側のWebサイトからクライアントに返されるさまざまなイベントを処理する必要があります。表4に、すべてのイベントの一覧と、それらがディスパッチされるタイミングを示します（HTML 5に関するドキュメントから引用）。

表4　メディアユーザーインターフェースのイベント

イベント名	インターフェース	ディスパッチのタイミング	前提条件
loadstart	Event	リソース選択アルゴリズムの一環として、ユーザーエージェントがメディアデータの検索を開始	networkStateがNETWORK_LOADINGに等しい
progress	Event	ユーザーエージェントがメディアデータのフェッチを実行	networkStateがNETWORK_LOADINGに等しい
suspend	Event	ユーザーエージェントが意図的にメディアデータのフェッチを現在行っていないが、メディアリソース全体のダウンロードが済んでいるわけでもない	networkStateがNETWORK_IDLEに等しい
abort	Event	ダウンロードの完了前にユーザーエージェントがメディアデータのフェッチを停止したが、この停止はエラーによるものではない	errorがMEDIA_ERR_ABORTEDというコードを持つオブジェクトである。networkStateがNETWORK_EMPTYとNETWORK_IDLEのどちらか（ダウンロード中止のタイミングに依存）に等しい
error	Event	メディアデータのフェッチ実行中にエラーが発生	errorがMEDIA_ERR_NETWORK以上のコードを持つオブジェクトである。networkStateがNETWORK_EMPTYとNETWORK_IDLEのどちらかに等しい
emptied	Event	メディア要素のnetworkStateがNETWORK_EMPTYの状態になった（レポート対象となる読み込み中に致命的なエラーが発生したか、リソース選択アルゴリズムがすでに実行されている状態でload()メソッドが実行されたことが原因。後者の場合、load()の呼び出しに同期してイベントが発生する）	networkStateがNETWORK_EMPTYであり、すべてのIDL属性が初期状態にある
stalled	Event	ユーザーエージェントがメディアデータのフェッチを試みたが、データがまだ用意されていない	networkStateがNETWORK_LOADINGである
play	Event	再生が開始された。play()メソッドからの復帰後に発生する	pausedがfalseになった
pause	Event	再生が一時停止された。pauseメソッドからの復帰後に発生する	pausedがtrueになった
loadedmetadata	Event	ユーザーエージェントがメディアリソースの長さと寸法を判定した	readyStateが初めてHAVE_METADATA以上の値になった
loadeddata	Event	ユーザーエージェントがメディアデータのレンダリングを現在の再生位置で初めて行えるようになった	readyStateが増加によって初めてHAVE_CURRENT_DATA以上の値になった
waiting	Event	次のフレームが利用不可のため再生を停止したが、ユーザーエージェントはそのフレームがやがて利用可能になると想定している	readyStateがHAVE_CURRENT_DATA以下の値になり、かつpausedがfalseである。seekingがtrueであるか、バッファリングされた範囲のいずれにも現在の再生位置が含まれていない。pausedがfalseになることなく、他の2つの理由（再生が終了したか、再生がエラーによって停止した）によって再生が停止する可能性がある
playing	Event	再生が開始された	readyStateがHAVE_FUTURE_DATA以上の値になったか、pausedがfalseであるか、seekingがfalseであるか、現在の再生位置がバッファリングされた範囲のいずれかに含まれる
canplay	Event	ユーザーエージェントはメディアデータの再生を再開できるが、今すぐに再生を開始すればコンテンツのさらなるバッファリングのために停止せずには現在の再生速度でメディアリソースを最後までレンダリングできないと予測している	readyStateが増加によってHAVE_FUTURE_DATA以上の値になった
canplaythrough	Event	ユーザーエージェントは、今すぐに再生を開始しても、コンテンツのさらなるバッファリングのために停止することなくメディアリソースを現在の再生速度で最後までレンダリングできると予測している	readyStateがHAVE_ENOUGH_DATAになった
seeking	Event	IDL属性であるseekingがtrueに変化し、ユーザーエージェントがこのイベントを発生させるのに十分な時間がシーク操作にかかっている
seeked	Event	IDL属性のseekingがfalseに変化した
timeupdate	Event	現在の再生位置の変化が、通常の再生に伴って、あるいは特に興味深い形（不連続的な変化など）で起こった
ended	Event	メディアリソースの終端に達したので再生が停止した	currentTimeがメディアリソースの終端に等しく、endedがtrueである
ratechange	Event	defaultPlaybackRate属性とplaybackRate属性のどちらかが更新された
durationchange	Event	duration属性が更新された
volumechange	Event	volume属性とmuted属性のどちらかが変化した。関連する属性セッターからの復帰後に発生する

　表4に示したイベントのなかで特に便利なものとして、canplayイベントとcanplaythroughイベントが挙げられます。canplayイベントは、すべてのデータの読み込みが終わっていなくても、ビデオプレーヤーが実際にコンテンツのレンダリングを意味のある形で開始できるだけのデータが読み込まれた時点で発生します。一方のcanplaythroughイベントは基本的に、ブラウザのバッファへのデータ読み込みが完全に済み、途中で再生を一時停止して残りのコンテンツを取得しなくてもビデオを最後まで再生できるようになった時点で発生します。

　リスト2に、こうしたイベントの使用例として、だれかがこのURLからOGVムービーにアクセスして［Load（読み込み）］ボタンを押す場合の処理を示します。

　ビデオの再生が可能な状態になると、oncanplayイベントのキャッチによって［Play（再生）］ボタンが有効になります。さらにユーザーが［Play（再生）］ボタンを押すと、ダウンロードされたビデオの再生が実際に開始されます。

リスト2　簡単なWebビデオプレーヤー

<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>HTML 5 Video</title>
        <script type="application/javascript">           
function Init_Handler(){
    var myVideo = $("myVideo")
    var playVideoBtn = $("playVideoBtn")
    var videoSrc = $("myVideoSrc").value;
    myVideo.src = videoSrc;
    myVideo.oncanplay = function(){ 
       if (myVideo.readyState == 4){
            playVideoBtn.removeAttribute("disabled");
            } 
         }
    myVideoBtn.onclick = function(){
         myVideo.play()
        } 
    myVideo.load();     };        
window.onload = Init_Handler;
        </script>
    </head>
    <body>        
        <video id="myVideo" width="320" height="240" src=""/><br/>        
        <input id="myVideoSrc" type="text" value=""/>        
        <input id="loadVideoBtn" type="button" value="Load"/>        
        <input id="playVideoBtn" type="button" value="Play" 

disabled="disabled"/>        
    </body>
</html>

　ただし、これは理論上の話です。実際のところは、Firefoxでさえ<video>タグや<audio>タグを完全には実装していないからです。そのため、こうしたイベントの多くはまだJavaScriptのレベルには渡されていません。つまり、実装がまだ完了していない現時点では、やはりload()のあとにplay()を呼び出すことが、外部で読み込まれたビデオリソースを再生するベストな方法のようです。ただし、こうした状況は実装（およびXHTML規格）の具体化に伴って変わってくる可能性が高いので、注意が必要です。

ブラウザベンダーが寄せる関心の高さ

　あらゆる点から見て、ブラウザベンダーがマルチメディア機能をHTML 5規格の開発における極めて重要な鍵として捉えていることは確かなようです。オーディオもビデオも複雑な部類のメディアであること、またWebブラウザ内でのビデオやオーディオの利用を促進できるという期待の高さを考えれば、当然のことでしょう。しかし、HTML 5のマルチメディアがどこでも使えるようになるには、最先端のブラウザ実装にさらなる技術的な進歩が求められそうです。

著者紹介

Kurt Cagle（Kurt Cagle）

ライター、情報アーキテクト、XML News NetworkとMetaphorical Webのウェブマスター。カナダ、ブリティッシュコロンビア州のビクトリア在住。XMLToday.orgの編集長、O'Reilly Mediaの寄稿編集者。現在、XBRLに関する著書を執筆中。彼のTwitterはtwitter.com/kurt_cagle。