しかし、1つの手がかり-コーデック。 ブラウザ開発者とコンテンツプロバイダーは、ビデオに使用するコーデックに同意しませんでした。 実際、この問題は以前に議論されており、まだコンセンサスはありません。 その結果、特定のコーデックへの参照はドラフトHTML5仕様から削除されました。
コーデック
HTML5ビデオのコーデックタイトルは、現在2つのコーデック（ Ogg TheoraとH.264）によって主張されています。
GGテオラ
Ogg Theoraは、On2 Technologiesが開発したVP3コーデックに基づいています。 2002年、On2 TechnologiesはVP3コードを無料のBSDのようなライセンスの下でXiph.org Foundationの手に移し、コーデックの特許も拒否しました（技術的には拒否しませんでした。 ） それ以来、Xiph.orgはこのコーデックの開発を続けています。
Ogg Theoraは、ライセンス料や特許料なしで、いつでもどこでも使用できます。
H.264
H.264は、ライセンスが必要なビデオ圧縮標準です。 その使用には、特許が適用される国での手数料が必要です（まず米国です）。 ただし、今日、これはビデオを圧縮する最良の方法の1つです。 たとえば、HDビデオの事実上の圧縮の標準であるのはH.264です。 H.264は、品質/ビットレートの点でOgg Theoraよりも著しく効率的です。
要するに、H.264は優れていますが、そのオープンソースの実装でさえ、特許が適用される国では自由に使用することはできません。
最新のブラウザーでの実装
ここでは、HTML5ビデオが現在機能しているブラウザーのみに言及します。
Mozilla Firefox
実装ではliboggplayライブラリを使用します。 つまり 、ビデオにはOgg Theora、オーディオにはOgg Vorbisしか使用できません。 つまり コーデックは修正されており、他の何かをサポートするには、基本的に実装を書き直す必要があります。
Google Chrome
実装では、静的にバインドされたffmpegを使用します。 ffmpegは、Ogg Theora、H.264など、さまざまなコーデックをサポートしています。一般的に、現在実際に使用されているほぼすべてのものがサポートされています。
ところで、ffmpegは現在ほとんど普遍的に使用されています-たとえば、fCPmはCCCPおよびK-Liteコーデックパック 、ならびにmplayerおよびVLCで使用されています。
すべてが素晴らしいようです。 しかし！ ffmpegはオープンソースですが、米国では無料ではありません。 ffmpegを使用してプログラムを配布するには、控除を支払う必要があります。 Googleはそれを買う余裕があり、組み込みのffmpegでビルドをリリースする権利があります。 しかし、これはLinuxディストリビューションには当てはまりません。 米国でリリースされたものは、リポジトリにffmpegサポート付きのChromeを含めることができません。これには控除料金が必要になるためです。 まず第一に、これはFedoraのような悪名高い配布キットに関するものです。
サファリ
対応するQuickTimeコーデックがインストールされている場合は何でも再生できるQuickTimeフレームワークを使用します。
これはおそらく最新の実装の中で最も正しいものです。 最初はモジュール式アーキテクチャです。 しかし、これらはすべてMac OSに強く結び付けられているため、他のシステムやブラウザーには適用できません。
厳しい現実
次に、コンテンツプロバイダーについて説明します。 自由
さらに、H.264の使用は、エンドユーザーにとってより有益です。 ロイヤリティを支払うことはありませんが、それでも、ダウンロードするデータを少なくして、より良いビデオ品質を得ることができます（脆弱なインターネットチャネルを持つ非資本の住民にこんにちは）。
すべてが悪いですか？
はい、はい。 しかし！ 抜け道があります。 ブラウザでビデオをデコードするには、特定のコーデックに縛られることなく、モジュール式のアプローチを使用する必要があります。 さらに、各オペレーティングシステムには既にコーデックのモジュラーインフラストラクチャがあります。 WindowsではDirectShow、Mac OS XではQuickTime、Linuxではgstreamerです。 ちなみに、gstreamerはクロスプラットフォームでもあり、すでにクロスプラットフォームプログラムで使用されています。たとえば、Songbirdはすべてのプラットフォームでgstreamerを使用して音楽を再生します。
gstreamerを使用すると、ブラウザーのコーデックに関するすべての問題が完全に解決されます。 特に、ブラウザは特許取得済みのコーデックなしで配信されるため、特許に関して問題はありませんが、ユーザーのシステムでは、このコーデック用にインストールされたプラグインを見つけて使用することができます。
さらに、gstreamerは、このシステムのネイティブフレームワークにインストールされたコーデックを使用する機能を提供します（Windowsの場合-DirectShow、Mac OSの場合-QuickTime）。
明るい未来、それは来るでしょうか？
Mozilla Firefox
実際に、 ここに 。 しかし、そこのコメントから判断すると、現在、そのような統合はFennecに対してのみ計画されています。 正直なところ、私は心からこのことに戸惑っています。 FirefoxのH.264サポートが必要であり、高速です。そうしないと、船外に放置される大きなリスクがあります。
現在、モジュラーアーキテクチャが必要であるという考えをFirefox開発者に伝える方法がわかりません。 頭に浮かんだのは、このバグに投票し、壊れたWebサイト（ヘルプ-壊れたWebサイトを報告...）について、このバグへのリンクを含むレビューを残すことだけでした。
Google Chrome
トラブル 。 私は拒否の理由を理解しようとしましたが、それは私にとってあまり重くないように思われました。 原則として、追加するものはありません。 あなたは議論を読むことができます、それはかなり暑いです。 このバグには引き続き投票できます（アスタリスクのマーク）。 あなたは決して知らない...
オペラ
突然、小さいが非常に頑固なノルウェーの会社は、非常に良い面から自分自身を示しています。 読んで、喜ぶ 。
他のブラウザ
巨大な巨人は、Epiphany、Midori、Auroraなどの広範なブラウザでほとんど使用されることのない、小さな背後に簡単に配置できます。 それらはすべてWebKitを使用します。 EpiphanyとMidoriはGtkWebKitを使用しており、gstreamerを介したHTML5ビデオのサポートを計画しています（または既に行っています）。 AuroraはQtWebKitを使用します。HTML5の場合、Phononを使用することが計画されている（または既に部分的に行われています）Phononは、gstreamerを含むさまざまなバックエンドを使用できます。
ただし、現時点では、HTML5をサポートする機能はありません。 それは非常に現実的であるため、彼らのすぐに明るい未来を信じることは残っています。
あとがきの代わりに
2010年がFlashの死とHTML5の勝利の年になることを心から願っています。