1990年代は、切手サイズの Apple QuickTime や Windows Media® 動画が、オンラインではないにせよ、コンピューターで再生されるというだけでも素晴らしいと考えられていました。QuickTime バージョン 1.0 が技術的なブレークスルーとしてリリースされたのは、1991年のことです。これに対し、Microsoft は 1992年に Video for Windows® で対抗しました。さらに 1995年には RealNetworks がインターネット経由のストリーミング・オーディオを再生可能にした初のメディア・プレイヤーである RealAudio Player をリリースしました。その後、1990年代後半から 2000年代初頭にかけて、一般ユーザーが利用可能なネットワーク帯域幅が拡大したことによってオンライン動画が可能になりました。主要なメディア・プレイヤーは、いずれもストリーミングやプログレッシブ・ダウンロードによるメディア再生を行うバージョンをリリースしました。2000年の時点で、動画は現実のものとなったとはいえ、当時はまだ標準化されていない混乱状態でした。
2000年代初頭のオンライン動画の品質はいい加減なものでした。RealNetworks の RealPlayer は最高のオンライン動画プレイヤーの 1 つに数えられていたかもしれませんが、度々のアップグレードでユーザーを煩わせていました。しかも、RealNetworks がユーザーの個人情報を保管しているという不名誉な疑惑もありました。QuickTime はそれよりも優れたオンライン動画プレイヤーでしたが、あくまでも Macintosh システム上での話であり、Windows 上では他のソフトウェアとの共存に問題があり、そのままではうまく機能しませんでした。こうした状況のため、ユーザーには常に、動画は再生されるのだろうか、スムーズに再生するのに十分なフレームを得られるのだろうか、リモートで音声は同期されるのだろうか、といった不安が付きまとっていました。
オンライン動画プレイヤーの進歩が続いたのは、そこまでです。2001年、ブラウザー戦争で勝利をおさめた Microsoft は Windows Internet Explorer® での技術革新への取り組みを事実上終了し、市場に次から次へと登場する機能によって生じるセキュリティー・ホールに重点を置くようになります。W3C は何の助けにもなりませんでした。HTML 仕様のバージョンアップは行わないことを宣言し、XHTML と XHTML2 にその焦点を移したからです。そのため、ベクトル・アニメーションや、ドメイン間通信、複数ファイルのアップロード、音声、動画などの革新的な機能を開発するには、Adobe® (当時の Macromedia) Flash® に頼らざるを得ませんでした。
2002年、Macromedia は Sorenson Spark を使用した Flash Video で開発者たちの要望に応え、翌年の 2003年には外部動画用 FLV フォーマットを導入しました。VP6 コーデックを使用した FLV フォーマットは当時、極めて高い品質と優れた圧縮能力を備えていました。2005年にサービスを開始した YouTube では、この FLV フォーマットのみが使用されました。Flash Player は大きなインストール・ベースを持っていること、Flash Video はほぼ完璧に機能すること、そして YouTube では単純なインターフェースで動画をアップロードして変換できることから、結果的に Flash Video が Web で動画を配信するためのデファクト・スタンダードとなりました。
けれども YouTube の外の世界では、オンライン動画を実装する際の困難は解消されていませんでした。Flash による動画を個人や会社の Web サイトに組み込む場合、Adobe ActionScript® と独自仕様のツールに関する確固たる知識がなければ、動画をエンコードしてプレイヤーのコントロールを作成できないのが通常です。Flash オブジェクトの組み込みコードを長年目にしていても、リスト 1 のような長々としたコードでは、実装の複雑さが緩和されることになりません。
リスト 1. Flash オブジェクトの組み込み例
<object id="UNIQUEID" height="520" width="528" codebase="http://download.macromedia.com/"
classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" >
<param value="../player/myVideoPlayer.swf" name="movie" />
<param value="true" name="allowFullScreen" />
<param value="all" name="allowNetworking" />
<param value="always" name="allowScriptAccess" />
<param value="opaque" name="wmode" />
<param value="myVideoFile.flv" name="FlashVars" />
<embed height="520" width="528" src="../player/mds_player.swf"
id="UNIQUEID" wmode="opaque" allowscriptaccess="always" allownetworking="all"
allowfullscreen="true" swf="../player/myVideoPlayer.swf"
flashvars="myVideoFile.flv"
pluginspage="http://www.macromedia.com/go/getflashplayer"
type="application/x-shockwave-flash" quality="high" />
</object>
|
他の動画プレイヤーの品質は次第に改善されてはいたものの、動画をユーザーのコンピューターで再生できるかどうかについての判断は難しいことから、使い易さの改善は一向に進んでいませんでした。その主な例は、WMV ファイルを再生する場合です。ブラウザーが Internet Explorer であれば、WMV は再生されます。けれどもブラウザーが Mozilla Firefox の場合にはどうなるでしょうか。Windows ではおそらく再生されるでしょう。Mac では再生されないはずですが、それでも再生される可能性がないわけではありません。このような事情から、各種のブラウザーおよび各種のオペレーティング・システムで機能する、これまでとは異なる動画フォーマットが必要となってきました。これまでとは異なる動画フォーマットということは、これまでとは異なるプレイヤーが必要なことを意味し、通常それは、複雑な JavaScript ソリューションを意味します。
HTML と World Wide Web は、Tim Berners-Lee の考えのとおり、無償で公開されることになりました。Lee が W3C を設立した目的は、「業界のメンバーが新たな標準の採択に合意し、互換性を確保する」ことです。けれども 2000年の時点では、W3C が XHTML の取り組みに追われている間、開発者たちは必死になって独自仕様の Flash プラグインに頼るしかありませんでした。
2007年、Opera は Web Hypertext Application Technology Working Group (WHATWG) ワーキング・ドラフトの中で、<video> タグを提案しました。その目的は、「Web ページに動画を組み込むと同時に、ブラウザーに動画のネイティブ・サポートを組み込むための簡単なオープン・ソリューションで、動画を Web の第一級市民にする」ことです。この <video> タグをリスト 2 に示します。このように、プラグインの場合に必要となる、オブジェクトが組み込まれた冗長なマークアップに比べ、遥かに簡潔でコーディング量も少なくなっています。
リスト 2. 単純な HTML5 動画の例
<video controls src="demo.ogg"></video> |
2009年 7月、W3C は XHTML に関する活動を終了し、HTML5 の取り組みを開始する予定であると発表しました。現在の最新のブラウザー (Windows Internet Explorer の場合はバージョン 9) は、いずれも <video> タグをサポートしており、API はほとんど一貫しています (ただし、一部の詳細は今でも流動的です)。
HTML5 動画には多くの利点があります。リスト 2 に示したように、HTML5 動画では単純に <video> タグとパラメーターを組み込むだけなので、JavaScript や ActionScript のコードは一切必要ありません。動画はブラウザーのプラグインではなく、第一級市民です。つまり、JavaScript コードを使用する場合、ページの準備が完了した時点で動画はすでに準備できているので、さらにプラグインがロードされるまで待つ必要がなくなるというわけです。いくつかの例外はあるにせよ、API は標準化されて、すべてのブラウザーで機能することになります。動画がネイティブな要素であれば、プラグインとの格闘 (CSS が変更された後にプラグインを再ロードするなど) も、表示との格闘 (動画によってスクロール・バーの使用が妨げられるなど) もなくなります。
HTML5 動画の仕様はまだ日が浅いため、問題はあります。最も明らかな問題は、Internet Explorer ではサポートされないことです (ただし、バージョン 9 のプレビュー版ではサポートされています)。ネイティブ UI コントロールは便利なものの、その外観と機能はブラウザー間で一貫していません。サード・パーティー製の動画プレイヤーをサンドボックス化するのが一層困難になり、最低限でも iframe が必要です。さらにこの仕様には、Flash で前提とされてきた強力な全画面表示機能がありません (ちなみに、最近になって Mozilla がこの問題に対する解決案を提出しました)。
ストリーミング、異なる帯域幅への対処、動画の取り込み、コンテンツの保護などといった多くの領域では、今でも Flash が断然に優れています。おそらく最も重要な点は、Flash では、1 つの動画ファイルをすべてのオペレーティング・システム上のすべてのブラウザーで再生できることです。このことから、ブラウザーのベンダーは HTML5 動画フォーマットだけにすることには同意できませんでした。したがって、現在のところは少なくとも 2 つの動画ファイルが必要です。
ブラウザーのベンダー間での同意を得られなかったことに対処するために、HTML5 仕様は異なるタイプの動画を処理するように変更されました (リスト 3 を参照)。
リスト 3. 複数のソースを使用した HTML5 動画
<video controls> <source src="demo.ogg" /> <source src="demo.webm" /> <source src="demo.mp4" /> </video> |
ブラウザーはソースのそれぞれを順番に再生しようと試みるため、Ogg 形式の動画を再生できない場合には、WebM 形式の動画を試し、次に MP4 形式の動画を試すことになります。ブラウザーがいずれの形式の動画も処理できない場合には、ファイルがロードされなかったことがわかるようにします。事実上、video 要素には後方互換性が備わっています。それは、ブラウザーがこの要素を認識しなければ、無視するだけだからです。この後方互換性を利用して、例えばリスト 4 に記載するような、お馴染みの要素を挿入するという方法を使えます。
リスト 4. フェイルオーバー用に画像を使用した HTML5
<video controls>
<source src="demo.ogg" />
<source src="demo.webm" />
<source src="demo.mp4" />
<img src="images/videoReplacement.gif" />
</video>
|
他のソリューションとしては、画像の代わりに Flash 組み込みオブジェクトを挿入する方法もあります。
HTML5 動画の API は、爽快なほどにシンプルです。ただし API の場合も同じく、まだ日が浅いため、流動的な部分があります。HTML5 仕様を主導するのは WC3 ではなく、ブラウザー・ベンダーであることを思い出してください。ブラウザー・ベンダー主導のプロセスは革新を促しますが、それと同時に、それぞれのブラウザーごとに他のブラウザーにはない独自の機能が使用される可能性もあります。そのような場合を除けば、表 1 に記載する API はサポート・ブラウザーの間でほとんど一貫しています。
表 1. HTML5 動画の API
| 属性 | プロパティー | メソッド | イベント |
|---|---|---|---|
src
| currentSrc
| play | play
|
属性とプロパティーとの違いは、プロパティーをマークアップの中で使用することはできませんが、属性はマークアップの中でもスクリプトの中でも使用できることです。また、<video> 要素の src 属性は、<source> 要素の src 属性よりも優先されるため、マークアップの中で <source> 要素を使用する場合にはその src 属性は空のストリングになります。上記のプロパティーのうち、コンテナーのサイズを設定する width と height は即時に使用することができます。この 2 つ以外は、動画のメタ・データがロードされた後に使用可能になります。
現時点で、ブラウザーには重大なバグは見つかっていませんが、Apple iPad については、現行の API に影響する以下のバグがあります。
- 動的な動画に関するバグ:
<video>要素にinnerHTMLが含まれていると、ソース要素が自動的に起動されません。これを解決するには、src属性を設定してloadメソッドを呼び出します。その一例については、リスト 5 を参照してください。 - ソースの順序に関するバグ: 最初のソース要素が MP4 形式以外の動画を対象としている場合、iPad はそこで停止し、ロードを行いません。この問題に対するソリューションは、MP4 形式を指定したソース要素を必ず最初に記載することです。
- ポスターに関するバグ: iPad はポスター画像を表示しません。このバグは近日中に修正されるはずですが、それまでの間は、ポスター画像の位置でフロートする HTML
IMG要素を作成することが解決策となります。
リスト 5. iPad の動的ロードに関するバグの修正
window.onload = function(){
var video = document.body.appendChild(document.createElement('video'));
if(video.canPlayType("video/ogg")){
video.src = "video/myMovie.ogv";
}else if("video/mp4"){
video.src = "video/myMovie.mp4";
}
video.load();
}
|
動画の開発に備えるためには、用語の意味、MP4 と Ogg との違い、そしてもちろん、動画をエンコードする方法を理解しておく必要があります。動画を話題にするときに重要となる主な用語は、ファイル形式とコーデックの 2 つです。
ファイル形式は、ラッパー、あるいはコンテナーとしても知られています。MP4、WebM、OGV はいずれもファイル形式です。このメタデータ・ファイル形式は、データの保管方法を記述し、コンピューターがファイルを表示するのに必要なライブラリーをロードできるように情報を提供します。ファイル形式には通常、動画コーデックと音声コーデックが記述され、この 2 つを同期させる方法をコンピューターに指示する命令が含まれます。
コーデックとは、画像や音声、その他のデータのデコードを処理するコードのことです。通常、コーデックにはエンコードされたデータの圧縮プロセスが組み込まれます。以下に、HTML5 動画が実装されたファイル形式とそれぞれに対応するコーデックを記載します。
- MP4: [H264 動画+AAC 音声] を使用
- WebM: [VP8 動画+Vorbis 音声] を使用
- Ogg: [Theora 動画+Vorbis 音声] を使用
現在 HTML5 動画でサポートされる形式は、MP4、Ogg、および WebM です。それぞれのブラウザーがサポートしているファイル形式は異なっているので注意してください (その最新情報を把握するのは、HTML5 動画でサポートされるファイル形式を把握するのと同様に大変です)。
表 2 に、各ブラウザーがサポートするファイル形式を記載します。
表 2. HTML 動画のファイル形式へのブラウザーごとの対応表
| ブラウザー | MP4 | Ogg | WebM |
|---|---|---|---|
| Internet Explorer 9 | サポート | 非サポート | 不確定 |
| Firefox 4.0 | 非サポート | サポート | サポート |
| Google Chrome 6 | サポート | サポート | サポート |
| Apple Safari 5 | サポート | 非サポート | 非サポート |
| Opera 10.6 | 非サポート | サポート | サポート |
注: Mac 上の Safari および Windows 上の Internet Explorer 9 は、そのファイル形式に対応するコーデックがオペレーティング・システムにインストールされていれば、そのファイル形式をサポートします。その他のブラウザー (Firefox、Opera、Chrome) には、サポート対象のファイル形式に対応する動画コーデックを実装する必要があります。
スマートフォンには通常、動画コーデックがハードウェアに実装されています。Apple の iPhone および iPad、さらには Android フォンは、付属のコーデックが対応しているファイル形式 (MP4) のみを再生します。RIM Blackberry 機器では 3GP の動画ファイル形式を扱いますが、このファイル形式でも H264 コーデックを使用します。
H264 コーデックは広く採用されていることから、どの編集ソフトウェアを選んだとしても、大抵は MP4 形式の動画にエンコードできるはずです。WebM は新しいファイル形式ですが、対応するツールはすでに登場しています。Ogg はオープンソースでありながらも、それほど広く使用されてはいないため、Ogg 用のツールはほんの少ししかありません。詳しい情報と技術については、「参考文献」セクションを参照してください。
動画をエンコードする際には、理解しにくい多くの用語を目にするものです。経験から推測して何らかのものを作り出すことはできるかもしれませんが、これらの用語をきちんと理解しておくと役に立ちます。その結果、低帯域幅ながらも高品質で、ストリーミングにもプログレッシブ・ダウンロードにも対応した動画を作成できるようになるだけでなく、どの機器でも動画が再生されない場合に問題をトラブルシューティングできるようになります。
- 可変ビット・レート (VBR) と固定ビット・レート (CBR): VBR では、現在処理を行っている画像の複雑さに応じてビット・レートを調整します。それに対し、CBR ではセグメントの複雑さに関わらず、動画全体を通して同じビット・レートを使用します。CBR は、ストリーミングで通常使用される手法です。
- マルチパス: この用語は、エンコードの際に 2 つのパスで処理を行うことを表しています。最初のパスでデータを分析し、2 番目のパスで最大限まで圧縮できるようにします。この機能は、ストリーミングでは使用されません。
- 正方/非正方ピクセル: この用語は、初期の動画変換ソフトウェアの時代に産み出された不幸の産物を表しています。この用語は基本的に、正方形ではないピクセルを使用した 720x480 と正方形のピクセルを使用した 640x480 のことを説明しています。誤った変換が適用されると、画像のアスペクト比が崩れてしまいます。
- レベル: これは H264 の設定です。全部で 16 種類あるレベルは基本的に、圧縮時にさまざまな動画コンポーネントに対する制約を簡単に指定する方法になります。
- プロファイル: プロファイルは、MP4 エンコード方式の機能の集合です。もっともよく使われているベースライン・プロファイルは、Web、ビデオ会議、モバイル・アプリケーションに使用されます。メイン・プロファイルは標準画質のデジタル TV 放送や高解像度の Web ブロードキャスト用、ハイ・プロファイルは特にブルーレイなどのブロードキャストおよびディスク・ストレージ・アプリケーション用です。
MP4 コンテナー、H264 動画コーデック、および ACC 音声コーデックは、MPEG LA Group の特許が適用される独自仕様の形式です。個人用の Web サイトや、少数の動画しか使用しないビジネスにとっては問題ではありませんが、多数の動画を使用するビジネスではライセンスと料金に細心の注意を払う必要があります。そのようなビジネスでは、ライセンスと料金が最終収益に影響を及ぼすことになりかねません。MP4 コンテナーとそのコーデックは、現在のところ、エンド・ユーザーに対しては無料となっています。
WebM コンテナーと Ogg コンテナー、VP8 および Theora 動画コーデック、そして Vorbis 音声コーデックはいずれも、使用料無料のオープンソースとして Berkeley Software Distribution License の下、無料で動画を作成し、配布し、表示することができます。ただし、VP8 が H264 特許の一部を侵害している可能性があるという噂も流れているので、常に最新の情報を入手してください。
MP4 は業界標準のファイル形式ですが、そうであり続けるという保証はありません。MP4 以外の形式を選択する理由は、以下のようにさまざまにあります。
Ogg Theora:
- 利点:
- 無料です。
- Linux® 上で動作します。
- 欠点:
- 広く使用されてはいません。
- ハードウェア・アクセラレーションは一切用意されていません。
- 使用例:
- わずかな数のファイルを保守する場合
- 小規模やサイトや個人用サイト
- 対応ソフトウェアが少ないことが問題でない場合
- オープンソースのファン向け
WebM:
- 利点:
- 無料です。
- 急速に受け入れられつつあります。
- 近日中に Flash で表示できるようになる予定です。
- ハードウェア・アクセラレーションのサポートが確立されつつあります。
- Google/YouTube によって支援されています。
- 欠点:
- MPEG LA による特許訴訟が始まる可能性があります。
- iPhone と iPad ではサポートされません。
- 使用例:
- 多数のファイルを使用するサイト
- 対応ソフトウェアの少なさが最終的な収益に影響しない場合
- Apple 製品に対するサポートを気にする必要がない場合
- 将来の成功に賭ける場合
MP4:
- 利点:
- 優れた開発による業界標準です。
- ファイルは最小限で、画像は極めて鮮明です。
- 広範にサポートされているハードウェア・アクセラレーションを使用します。
- 欠点:
- デコードにプロセッサーを駆使するため、ハードウェア・アクセラレーションが必要です。
- ライセンス料金がかかります。
- WebM で Google が成功するかどうかは不確かです。
- 使用例:
- 総合的なサポート面およびビューアーの導入に最適
- Flash プレイヤーを組み込めば、すべてのブラウザーおよび新しいモバイル・プラットフォームで再生可能
- 動画のバージョンを 1 つに統一することが望まれる場合の最善のソリューション
この記事ではインターネットの黎明期から、現在の状態に至るまでのデジタル動画の進化を辿りました。どこででも機能する 1 つのフォーマットだけを使用できれば理想的ですが、それは現実的なシナリオではありません。動画コーデックが使用する技術は非常に高度で、作成するには何年もかかります。それは、Web のライフサイクルのスピードを考えると、まるで氷河が進むようなゆっくりした速さです。ある動画フォーマットが優勢になると同時に、別の動画フォーマットがその地位を奪う勢いで浮上するなか、この記事で定めたルールに従うとともに多少の先見の明を利かせれば、どの動画フォーマット (あるいは複数の動画フォーマット) を使用するのかを決めるのは、難しい話ではありません。
学ぶために
- WHATWG: WHATWG の動画仕様を読んでください。
- Opera はこのブログで、HTML5 動画仕様を提案しています。
- Opera HTML5 動画を作成するためのリソース、API、およびヒントについて説明しています。
- MP4 H264 特許を所有する MPEG LA Group について詳しく読んでください。
- WebM Project のホーム・ページから、ロードマップおよびリソースにアクセスできます。
- Ogg ファイル形式を扱うメインのサイトにアクセスしてください。
- developerWorks Web development ゾーンでは、多種多様な Web ベースのソリューションを話題にした記事を揃えています。
- developerWorks の Technical events and webcasts で最新情報を入手してください。
- developerWorks の on-demand demos で、初心者向けの製品のインストールおよびセットアップから熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
製品や技術を入手するために
- FFmpeg コマンドライン・ツールについて調べてください。WebM、MP4、Ogg をはじめ、さまざまな形式をエンコードするツールです。
- DirectShow Filters プラグインは WebM をエンコードします。
- WebM および Ogg 対応のオンライン動画変換ツール、Firefogg について学んでください。
- HandBrake GUI は MP4 をエンコードします。
- MPEG Streamclip GUI も同じく MP4 をエンコードします。
議論するために
- 今すぐ My developerWorks で自分のプロフィールを作って、HTML5 に関するウォッチ・リストをセットアップしてください。My developerWorks とずっとつながっていられます。
- Web 開発に興味を持つ他の developerWorks メンバーを見つけてください。
- Web のトピックを専門とする developerWorks グループに参加して、知識を共有してください。
- Roland Barcia が彼のブログで Web 2.0 とミドルウェアについて語っています。
- developerWorks のメンバーが共有する Web 関連のブックマークをフォローしてください。
- Web 2.0 Apps フォーラムで、素早く回答を得てください。

Mike Wilcoxは、テキサス州フリスコにある急成長の新興企業、BetterVideo の技術ディレクターとして、フロントエンドのエンジニアリングおよびオンライン動画サービスを担当しています。彼は Ajax などの Web 技術でお馴染みの講演者で、2009 Rich Web Experience や 2009 Dallas TechFest などのコンファレンスでも講演を行いました。彼はオープンソースの取り組みとして、Dojo Toolkit のディスプレイに Multi-File Uploader、音声および動画コンポーネント、ベクトル・ベースの DojoX Drawing などのマルチメディア技術を実装しました。