メディア・フラグメントURI 1.0(基礎)

メディア・フラグメントの指定においては、どちらのアプローチ - URIクエリとURIフラグメント - も有用です。URIクエリとURIフラグメントの主な違いは、URIクエリでは新しい資源が作成され、URIフラグメントでは一次資源と関係がある二次資源が提供されるという点です。URIフラグメントは、別の検索を行わずに一次資源で解決されます。これは、ユーザ・エージェントは、サーバーから別のデータを取得する必要なく、すでに受信済みの資源でURIフラグメントを解決可能であるべきということを意味します。

この仕様では、検索されたフラグメントのメディア・タイプが一次資源のメディア・タイプと同じであるべきというさらなる制約を設けています。これは、中でも、長い動画の中の1つの動画フレームを指し示すURIフラグメントは、静止画像ではなく、1フレームの動画になるということを意味します。静止画像を抽出するためには、URIクエリのスキームを作成する必要があります - ここでは考察していませんが、簡単に考案できます。

ユーザ・エージェントは、メディア・フラグメントURIを自ら解決し制御するかもしれません。最も簡単なケースは、ユーザ・エージェントが資源全体をすでにダウンロードしていて、そのローカルにキャッシュされたコピーから抽出を実行できる場合に生じます。一部のメディア・タイプでは、特別なプロトコルの力を借りずに、ネットワーク経由で抽出を実行することも可能です。時間フラグメントの場合は、ユーザ・エージェントが、既存のプロトコル・メカニズムを用いてメディア資源をシークできる必要があります。

メディア・フラグメントを指定するために用いるURIフラグメントの例は、http://www.example.org/video.ogv#t=60,100です。この場合、ユーザ・エージェントは、一次資源がhttp://www.example.org/video.ogvであり、#t=60,100というフラグメントと関連する一次資源の部分、つまり、60～100秒のみが表示されると予想されることを認識できます。したがって、一次資源とメディア・フラグメントとの関係は維持されます。

従来のURIフラグメント検索では、ユーザ・エージェントは、完全な一次資源をサーバーにリクエストした後に、ローカルにフラグメント化を適用していました。メディア・フラグメントの場合は、それによって完全なメディア資源を検索することになり、ユーザ・エージェントは、その後にそれに対してフラグメント抽出をローカルに実行することになるでしょう - 一般的に、そのような大きな資源に対しては実行できません。したがって、メディア資源は、HTTP上でリクエストを1回行うことで検索されるとは限りません。元の資源URIの一連のバイト範囲のリクエストとして検索されるか、それぞれがメディアの小さな部分を表す異なるURIに対する一連のリクエストとして検索できます。そのようなメカニズムの理由には、他の作業に使用できる帯域幅を最大化するために、クライアントが再生時に時間をかけて間隔を開けてリクエストを配置することを選択する帯域幅制約(bandwidth conservation)と、クライアントが現在の帯域幅の可用性に応じて変化するビットレートの様々な表現の中から選択する帯域幅適応(bandwidth adaptation)が含まれます。

メディア・フラグメントをバイト範囲にマッピングする方法を知っているユーザ・エージェントは、上記の例のようなURIフラグメントのリクエストを自身で満たすことができるでしょう。これは、一般的に、ネットワーク上のメディア・フラグメントをシークする方法を知っているユーザ・エージェントの場合に当てはまります。例えば、シーク可能な構造のインデックスが含まれているメディア・ファイルを扱うユーザ・エージェントは、そのインデックスから、メディア・フラグメントのアドレスをバイト範囲に対して解決できます。これは、例えば、シーク可能なQuickTimeファイルの場合に当てはまります。別の例は、一連のバイト範囲のリクエストによってメディア・ファイルをシークする方法を知っていて、最終的に正しいメディア・フラグメントを受信するユーザ・エージェントです。これは、例えば、3.5以降のバージョンのFirefoxにおけるOggファイルの場合に当てはまります。

同様に、メディア・フラグメントを一連のURIにマッピングする方法を知っているユーザ・エージェントは、URIフラグメントのリクエストを自身で満たすことができます。これは、一般的に、アダプティブ・ストリーミングを実行するユーザ・エージェントの場合に当てはまります。例えば、一連のURI(それぞれ、数秒間のメディア・ファイル)が含まれているメディア資源を扱うユーザ・エージェントは、そのURIのサブシーケンスに対してメディア・フラグメントのアドレスを解決できます。これは、QuickTimeアダプティブ・ビットレート・ストリーミングまたはIISスムーズ・ストリーミングの場合に当てはまります。

もし、そのようなユーザ・エージェントが、このドキュメントで規定しているメディア・フラグメント構文をネイティブにサポートしていれば、フラグメントと特定の次元に関して、この仕様に適合していると考えられます。

説明したURIフラグメントの指定方法は、個々の基盤要素が扱うことができるメディア・フラグメントとバイトの間の単純なマッピングを想定しているため、バイトが同じ(byte-identical)メディア資源のセグメントにのみ機能します。バイトの同一性の維持が不可能であり、資源の何らかのトランスコーディングが必要な場合、ユーザ・エージェントは自身ではフラグメント化を解決できず、サーバーの相互作用が必要です。この場合、URIクエリでは、サーバーとの相互作用が生じ、トランスコードされた資源を配信できるため、URIクエリを用いる必要があります。

URIクエリの別の用法は、ユーザ・エージェントが、既存の(一次)資源の単なるバイト範囲ではなく、完全に新しい資源を実際に受信したい場合です。これは、例えば 、メディア・フラグメント資源のプレイリストの場合です。URIフラグメントでメディア・フラグメントを解決できたとしても、URIクエリの方が望ましいでしょう。なぜなら、自身は元の一次資源の負担を負わなくてすむからです - ファイルのヘッダーは小さくなりえ、時間長は小さくなりえ、元の一次資源の残りの部分への自動的なアクセスは認められません。

URIクエリを用いる場合には、さらに、検索の実行により、完全に有効な新しい資源が確実に作成されなければなりません。例えば、Ogg形式の場合、これは、新しい資源(例えば、開始時間がゼロでない、エンコーディング・パラメータが異なるなど)を正確に記述するためにOggヘッダーを再構成することを意味します。ウェブ・プロキシでは、そのような資源は、元の一次資源とは異なる資源としてキャッシュされます。

メディア・フラグメントの仕様が含まれているURIクエリの例は、http://www.example.org/video.ogv?t=60,100です。これにより、40秒間の動画が作成されます(元の動画の長さが100秒を超えていると仮定して)。この資源は、元の一次資源と本質的に関係性を有していないことに注意してください。ユーザ・エージェントがそのような(例えば、HTML5のvideo要素を有する)URIを用いると、ブラウザには元の資源に関する情報がないため、このビデオを0秒から始まる40秒間の動画として表示することしかできません。元の資源のコンテキストは失われます。

ユーザ・エージェントは、URIの情報と一致させるために、資源の元の開始時間を動画の開始時間として表示したいかもしれません。これは、次の2つの方法のいずれかで達成できます。それは、動画ファイル自身に、それが別のファイルから抽出されたものであり、オフセットで始まるという何らかの情報が含まれているか - 検索された資源がどの元の一次資源に関連しているかをユーザ・エージェントが検索を通じて知り、別の検索でそれに関する情報を発見できるかのいずれかです。

自身に関する必要な種類の情報を含んでいるメディア資源の例は、Oggファイルです。スケルトン・トラックを有し、一次資源から正しく作成されたOggファイルは、上記の例でいうと、開始時刻が0秒ではなく60秒であることを知っているでしょう。ブラウザは、受信したビットストリームからこの情報を簡単に解析でき、望む場合には、60秒で始まり100秒で終わるタイムラインをビデオ・コントロール内に表示できます。別の選択肢は、ブラウザがURIを解析し、メディア資源が標準に従ったフラグメント仕様をどのように有しているかを知ることです。それにより、ブラウザがクエリのパラメータを解釈し、正しい開始・終了時間と、元の一次資源の抽出も行えます。そして、60秒で始まり100秒で終わるタイムラインをビデオ・コントロール内に表示することもできます。さらに、必要に応じて、右クリック・メニューをクリックして元の資源を表示することができます。

ビデオ・コントロールが0秒でも60秒でも始まらないユースケースは、メディア・フラグメントURIのリストによって作成されたマッシュアップ動画です。このようなプレイリストでは、ユーザ・エージェントは、フラグメントごとに個々のタイムラインの集合を表示するではなく、すべてのメディア・フラグメントを通した1つの連続するタイムラインを表示したいと考える可能性があります。したがって、60秒から100秒のフラグメントは、例えば、3分20秒からの4分間にマッピングできます。

メディア・フラグメントを検索するためにURIクエリを実行するために、新しいプロトコル・ヘッダーは必要ありません。このドキュメントの後半で、情報交換を向上させるいくつかのオプションのプロトコル・ヘッダーを推奨します。

名前―価の対のリストは、URIのクエリまたはフラグメントの要素でエンコードされます。名前と価の要素は、等号(=)で区切られ、複数の名前―値の対は、アンパサンド(&)で区切られます。

メディア・フラグメントは、次の2つの次元に沿ったメディアの指定をサポートしています(基礎バージョン)。

時間(temporal)

この次元は、「10秒で始まり、20秒まで継続する」などの、元のメディア内の特定の時間範囲を表します。

空間(spatial)

この次元は、「最も左上の座標が(10,10)である(100,100)の大きさの矩形」などの、元のメディア内の特定の範囲のピクセルを表します。

次元ごとに、いくつかの有効なメディア・フラグメントとそのセマンティクスを示しています。

構文エラーとセマンティックなエラーは、同じように扱われます。より具体的に言うと、ユーザ・エージェントは、URI構文に基づいて発見可能なエラーを引き起こす名前―値の対を無視すべきです(SHOULD)。次元ごとに詳細を下記で示します。様々な次元のエラーを検証し、その後の小項目でその値を検証します。より一般的なレベルのエラーから始めます。

ユーザ・エージェントが元のメディアの情報を持っている場合にのみ検出可能なエラーは、様々な扱いをされます。このような情報の例は、動画の時間長、画像の解像度、トラック情報、メディア資源のMIMEタイプ(つまり、URIのみに基づいて発見不可能な情報すべて)です。この情報の多くが設定情報内にあることに注意してください。次元ごとに詳細を下記で示します。

メディア・フラグメントを扱う時には、メディア・フラグメントをコンテキスト内に表示するのか、コンテキストなしに表示するかという問題があります。一般的には、URIフラグメントは、より大きな資源の一部であるため、コンテキスト内に表示することを推奨します。一方で、URIクエリでは、その結果として新しい資源が作成されるため、コンテキストなしに完全な資源として表示することを推奨します。次の段落では、座標軸ごとに、メディア・フラグメントのコンテキストについて論じ、そのコンテキスト内でのURIフラグメントの視覚化について提案を行います。

時間のURIフラグメントの場合、フラグメントの開始と等しい時間オフセットで再生を開始し、フラグメントの終了時点で休止することを推奨します。再度「再生」ボタンが押されれば、資源が読み込まれ、フラグメントの終了時点を超えて再生され続けるでしょう。特定のオフセットをシークすると、資源は、そのシーク・ポイントから読み込んで再生します。URIフラグメントのみを再生するために、「再読み込み」ボタンを導入することもお勧めします。このように、URIフラグメントは基本的に「焦点を絞る」ことを意味します。さらに、時間のURIフラグメントをトランスポート・バーで強調することもできます。

空間のURIフラグメントの場合、コンテキスト内の空間領域を強調することと、その領域を切り取ることの、2つの異なるユースケースが予想されます。最初のケースでは、空間領域をバウンディング・ボックスで示すか、背景(つまり、領域に含まれないすべてのピクセル)をぼかしたり暗くしたりすることができます。2番目のケースでは、切り取られた範囲としてその領域のみが示されます。ドキュメントの作者がどちらのユースケースを意図しているかを指定する方法は、この仕様の範囲外で、仕様の実装者が、属性やスタイルシートの要素などにより、そのための手段を提供することをお勧めします。

最後に、トラックのURIフラグメントの場合、トラックのURIフラグメントで識別されるトラックのみを再生することを推奨します。トラックが指定されなければ、デフォルトのトラックが再生されるべきです。ドロップダウン・ボックスやボタンを用いて別のトラックを選択し、選択したトラックを再生中に強調することができます。ユーザ・エージェントが、特定資源の利用可能なトラックに関する情報を検索する方法は、この仕様の範囲外です。

解決の順序: 1つのURIフラグメントのリクエストで複数の次元が組み合わされている場合、実装では、まず、コンテナ・レベルで時間、id、トラックの選択を行い、その後に空間コーデック・レベルで空間のクリッピングを行います。

メディア・フラグメントの文法: メディア・フラグメントURIの文法が、この仕様で標準化している機能の文法のみを規定することに注意してください。文字列が正しく解析されなくても、URIが誤りであるとは限らず、この仕様に従ったメディア・フラグメントURIではないことを意味するだけです。それは、何らかの拡張形式や、全く別のフラグメントの指定方法としては正しいかもしれません。そのため、メディア・フラグメント指定子の構文エラーに対するエラー回復は賢明ではありません。

外部クリッピング: メディア・フラグメントURIが別のクリッピング方式で用いられるような状況に関しては、絶対的な解決方法はありません。形式的には、外部のクリッピング方式がメディア・フラグメントURIを上書きするかカスケードするか、つまり、結果として作成される資源で定義されるかどうかを決定するのは、メディア・フラグメントURIを組み込む状況次第です。強い理由がなければ、カスケーディングをお勧めします。例は、<smil:video clipBegin="5" clipEnd="15" src="http://www.example.com/example.mp4#t=100,200"/>というSMIL要素です。これは、元のメディア資源の再生が105秒で始まり、115秒で停止すべきです。

メディア・タイプ: URIフラグメントのリクエストで検索される資源のメディア・タイプは、一次資源と同じです。したがって、動画から1フレームを検索すると、1フレームの長さの動画が作成されるでしょう。動画資源からすべての音声トラックを検索すると、音声資源ではなく、動画が作成されるでしょう。URIクエリのアプローチを用いる場合は、メディア・タイプの変更が可能です。例えば、特定の時間オフセットの動画の空間フラグメントは、リクエストの特定のHTTP「Accept」ヘッダーを用いてJPEGとして取得できます。

同期: ある資源のメディア・フラグメントを検索する際には、そのメディア資源の異なるトラックの間の同期を維持する必要があります。これは、URIフラグメントとURIクエリ検索の両方に当てはまります。URIクエリでは、トランスコーディングが必要な場合、同期では知覚できない変更が許容されます。

組み込みタイムコード: メディア資源にタイムコードが組み込まれている場合には、特にURIフラグメント方式を用いる場合に、メディア・フラグメントの検索のためにこれを維持する必要があります。URIクエリが用いられ、トランスコーディングが行われる時には、組み込まれたタイムコードは、それが有用で必要なときに残すべきです。

適度なクリッピング: 時間のクリッピングは、メディア・フラグメントが指定したものにできる限り近く、リクエストされたデータが割愛されていないものである必要があります。「適度に近い」とは、 リクエストされたフラグメントが完全に含まれている、リクエストされたフラグメントと最も近い圧縮エンティティを意味します。時間フラグメントの場合、http://www.example.org/video.ogv#t=60,100に対してリクエストが行われたものの、これは音声と動画のパケット境界が存在する場所であるという理由により、最も近いデコード可能な範囲がt=58,102であれば、返されるのはこの範囲になるだろうということを意味します。その後に、ユーザ・エージェントは、リクエストされた部分の一部のみを表示でき、また、それを行うのみであるべきです。これは、一部のコンテナ形式では問題とはなりません。なぜなら、コンテナ形式では、論理的な開始時点と終了時点の指定が認められているためです。

適度なバイト範囲: 1つの時間範囲のリクエストの結果として不釣り合いなほど多くのバイト範囲が発生する場合は、サーバーがメディア・フラグメントのクエリ・フォームにリダイレクトを返す方が良いかもしれません。このような状況は、基礎となるメディア・ファイルが奇妙な方法で構成されている場合に発生しえます。

メディア・フラグメントURIは、メディア資源のみに定義されます。しかし、動画や音声を備えたウェブ・ページを作成するウェブ開発者の多くは、そのウェブ・ページにURIスキームを提供することで、メディア・フラグメント(特に、動画の時間オフセット)に直接ジャンプする機能をユーザに提供したいと考えます。別のサーバーの相互作用を必要とせずにこれを実現する方法は、JavaScriptで解析されたウェブ・ページ上のURIフラグメント・スキームを用いて、メディア・フラグメントを音声または画像の資源ローダに伝達することです。HTML5では、適切な<audio>または<video>要素の@src属性を、適切なURIフラグメントで変更した後に、load()機能を呼び出して、要素にそのURIで資源に(再)読み込みさせる必要があります。

このようなウェブ・ページのURIスキームには、この仕様で定義している、アンパサンドで区切られた名前―値の対があり、例えば、http://example.com/videopage.html#t=60,100&xywh=12,12,42,42です。しかし、ウェブの開発者は、ウェブ・ページのフラグメント指定機能の残り部分でうまく機能するスキームを作成する必要があります。例えば、ウェブ・ページが、そのページの要素のID属性を用いてページを下方へスクロールする場合に、ウェブ・ページのアドレス指定にメディア・フラグメントURI指定を追加すると失敗するでしょう。例えば、 http://example.com/videopage.html#firstがうまく機能してそのウェブ・ページのオフセットまでスクロールする場合、http://example.com/videopage.html#first&t=60,100では同じスクロールは行われません。そのため、ウェブの開発者は、フラグメントのパラメータを解析し、scrollTo()関数またはscrollTop()関数を用いて、JavaScriptでスクロール機能を手動で実装する必要があります。