複数の<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を示します。
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();
