CyberLibrarian

【注意】 このドキュメントは、W3CのMedia Fragments URI 1.0 (basic) W3C Recommendation 25 September 2012の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2017年09月07日


W3C

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

W3C勧告 2012年9月25日

本バージョン:
http://www.w3.org/TR/2012/REC-media-frags-20120925/
最新バージョン:
http://www.w3.org/TR/media-frags/
旧バージョン:
http://www.w3.org/TR/2012/PR-media-frags-20120315/
編集者:
Raphael Troncy, EURECOM
Erik Mannens, IBBT Multimedia Lab, University of Ghent
Silvia Pfeiffer, W3C Invited Expert
Davy Van Deursen, IBBT Multimedia Lab, University of Ghent
貢献者:
Michael Hausenblas, DERI, National University of Ireland, Galway
Philip Jagenstedt, Opera Software
Jack Jansen, CWI, Centrum Wiskunde & Informatica, Amsterdam
Yves Lafon, W3C
Conrad Parker, W3C Invited Expert
Thomas Steiner, Google, Inc.

このドキュメントに対する正誤表を参照してください。規範的な修正が含まれているかもしれません。

翻訳版も参照してください。


要約

このドキュメントは、メディア・フラグメント1.0(基礎)の仕様を記述しており、メディア・フラグメントURLを構築するための構文を規定し、それをHTTPプロトコル上で用いる時の処理方法について説明しています。構文は、メディア資源を特定のフラグメントに限定するためにURIフラグメントとURIクエリ・リクエストで使用できる特定の名前―値の対の仕様に基づいています。メディア・フラグメントWGには、すべての対象となるメディア・タイプのレジストリを更新する権限がありません。メディア・タイプの所有者が、既存のスキームを、このドキュメントで提案しているものと調和させ、そのメディア・タイプ登録にフラグメントのセマンティクス仕様を更新または追加することを推奨します。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/W3C技術報告インデックスにあります。

これは、メディア・フラグメントURI 1.0(基礎)仕様の勧告です。これは、W3C Video on the Web Activityの一部であるメディア・フラグメント・ワーキンググループが作成したものです。W3Cは、ドキュメントが安定していると考えられ、開発者コミュニティによる実装が奨励されることを示す勧告として技術報告書を公開します。

このドキュメントに関してコメントを行いたい場合には、public-media-fragment@w3.orgメーリング・リスト(公開アーカイブ)にお送りください。

勧告案段階の結果として、編集上の変更のみが行われました(差分を参照)。実装報告が入手できます。

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

目次

1 はじめに
2 標準化の課題
    2.1 用語
    2.2 メディア・フラグメントの標準化
        2.2.1 URIフラグメント
        2.2.2 URIクエリ
3 URIフラグメントとURIクエリ
    3.1 どのような場合にURIフラグメントを選択する? どのような場合にURIクエリを選択する?
    3.2 ユーザ・エージェント内のURIフラグメントの解決
    3.3 クエリの解決
    3.4 URIフラグメントとURIクエリの組み合わせ
4 メディア・フラグメント構文
    4.1 一般的な構造
    4.2 フラグメント次元
        4.2.1 時間次元
        4.2.2 空間次元
5 メディア・フラグメントの処理
    5.1 メディア・フラグメントURIの処理
        5.1.1 名前―値要素の処理
        5.1.2 名前―値リストの処理
    5.2 HTTPのURIフラグメントとクエリ解決ためのプロトコル
6 メディア・フラグメント・セマンティクス
    6.1 有効なメディア・フラグメントURI
        6.1.1 有効な時間次元
        6.1.2 有効な空間次元
    6.2 URI構文に基づいて発見可能なエラー
        6.2.1 一般的なURIレベルのエラー
        6.2.2 時間次元のエラー
        6.2.3 空間次元のエラー
    6.3 元のメディアの情報に基づいて発見可能なエラー
        6.3.1 一般的なレベルのエラー
        6.3.2 時間次元のエラー
        6.3.3 空間次元のエラー
7 実装者に対する注(非規範的)
    7.1 メディア・フラグメント表示用ブラウザ
    7.2 メディア・フラグメント表示用クライアント
    7.3 すべてのメディア・フラグメントのクライアント
    7.4 メディア・フラグメント・サーバー
    7.5 メディア・フラグメント・ウェブ・アプリケーション

付録

A 参考文献
B URIに関するABNF構文のまとめ(非規範的)
C 謝辞(非規範的)


1 はじめに

現在、World Wide Webの音声と動画資源は「外部(foreign)」オブジェクトとみなされており、メディア資源をデコードし、インタラクションを行えるプラグインを用いる場合にのみ埋め込むことができます。一般的に、資源全体を検索せずに、動画の時間オフセットに直接アクセスするなどのサーバー・サイドの機能を備えるためには、特定のメディア・サーバーが必要です。このようなメディア・フラグメントのアクセスに対するサポートは、メディア形式によって異なっており、そのようなコンテンツをウェブで扱う標準的な手段が妨げられています。

この仕様では、メディア形式に依存しない、URI(Uniform Resource Identifier)を用いてウェブ上でメディア・フラグメントを指定するための標準的な方法を提供します。このドキュメントでは、メディア・フラグメントを、時間、空間、トラックなどのいくつかの異なる次元に沿って捉えています。時間フラグメントは、名前で指し示すことができ、そのID次元(id dimension)により、その名前を用いてURIで指定できます。規定のアドレス用スキームは、主に音声と動画資源に適用され、空間フラグメントの指定は画像にも使用できます。

この仕様の目的は、時間ベースのウェブ資源の部分の指定と検索をサポートするためにウェブ基盤を強化し、その部分を再利用するための自動処理の強化を行うことです。利用例は、電子メールによる友人とのフラグメントURIの共有、検索エンジンのインタフェースでのフラグメントURIの自動作成、RDFを用いたメディア・フラグメントのアノテーションなどです。この仕様の、このようなユースケースの例やその他の付帯条件、そして、既存のメディア・フラグメントの指定方法の調査を、メディア・フラグメントのユースケースと要件ドキュメントの要件で提供しています。

2 標準化の課題

2.1 用語

「しなければならない(MUST)」、「してはならない(MUST NOT)」、「すべきである/する必要がある(SHOULD)」、「すべきでない/する必要がない(SHOULD NOT)」というキーワードは、RFC 2119で記述されているように解釈されるべきです。

RFC 3986によると、「URI」という用語には相対的な参照は含まれません。このドキュメントでは、URIと相対的な参照の両方について考察します。そのため、我々は「URI参照」という用語をRFC 3986で定義されているとおりに用います(4.1項)。しかし、簡潔さのために、このドキュメントでは、「メディア・フラグメントURI参照」の代わりに「メディア・フラグメントURI」という用語のみを用います。

このドキュメントでは、次の用語を頻繁に用いており、それらを明確に理解しておく必要があります。

  • URIフラグメント:フラグメント要素は、番号記号(「#」)文字で示され、URIの末尾で終了する。
  • URIクエリ:クエリ要素は、最初の疑問符(「?」)文字で示され、番号記号(「#」)文字またはURIの末尾で終了する。
  • メディア・フラグメントURI:メディア資源の部分を指定するURI - URIクエリまたはURIフラグメントによるものでありえる。

2.2 メディア・フラグメントの標準化

メディア・フラグメントの標準化は、URIの仕様であるRFC 3986を基礎としています。ここでいう、URIでのメディア・フラグメント識別情報の提供とは、URIフラグメントまたはURIクエリの構造の指定を意味します。このドキュメントでは、URIフラグメントとURIクエリを構造化してメディア・ドキュメントを識別する方法を説明しています。メディア・フラグメントを指定するために、URIフラグメントとURIクエリで用いる名前―値のパラメータを標準化しています。これは、既存のCGIパラメータの規定を基にしています。この項では、メディア・フラグメントURIの構造を標準化する意義について考えます。

2.2.1 URIフラグメント

URIの仕様であるRFC 3986は、3.5項でURIフラグメントの形式について述べています。

「フラグメントの形式と解決は、[..]検索されうる表現のメディア・タイプ[RFC2046]に依存する。[..]フラグメント識別子のセマンティクスは、URIスキームに依存せず、それゆえ、スキームの仕様により再定義することはできない。」

これは、(RFC 4288で定義されている手順により登録されている)メディア・タイプ定義のみが、そのMIMEタイプのURIフラグメントに標準的な構造を導入できるということを本質的に意味します。メディア・タイプの登録手順の一部に、そのメディア・タイプと共に利用するためのURI内のフラグメント識別子の構築方法に関する情報を含むことができます。

URIフラグメント構築規則の登録は、RFC 4288の4.11項で示されているとおり、SHOULD-要件です。メディア・フラグメント・ワーキンググループには、すべての対象となるメディア・タイプのレジストリを更新する権限がありません。すべてのメディア・タイプ登録を分析したところ、現在、audio/*、image/*、video/*系のほんのわずかのメディア・タイプ登録のみでフラグメントまたはフラグメントのセマンティクスが定義されていることが分かりました(例えば、SVG 1.1、17章のSVGのフラグメントの定義を参照)。我々が知る限り、メディア・タイプでは登録されていないけれども、実際にフラグメント形式が指定されているメディア・タイプ(Ogg、MPEG-4およびMPEG-21が含まれる)はほとんど存在していません。さらに、これらのフラグメント形式を実際にサポートしているソフトウェア・パッケージは少しのみです。それ以外のすべてに関しては、フラグメントのセマンティクスは未知とみなされます。

そのため、このドキュメントの目的は、URIフラグメントでメディア・フラグメント(つまり、メディア資源の部分)を指定するためのURIフラグメントの構造化方法と、一般的に合意される次元指定の仕様を、audio/*、image/*、video/*系のすべてのメディア・タイプの所有者に提案することです。メディア・タイプの所有者が、既存のスキームとこのドキュメントで提案しているスキームとを調和させ、メディア・タイプ登録のフラグメントのセマンティクス仕様を更新または追加することを推奨します。

2.2.2 URIクエリ

URIの仕様であるRFC 3986は、3.4項でURIクエリの形式について述べています。

「クエリ要素は[..]、URIのスキームと命名オーソリティ(もしあれば)の範囲内の資源を識別するために利用できる。[..]クエリ要素は、「キー=値」という対の形式で識別情報を伝えるためにしばしば使用される[..]。」

URIクエリの仕様は、URIスキームと密接に関係しており、クエリ要素を用いることすらないものもあります。ここでは、HTTP RFC 2616とRTP/RTSP rfc2326のプロトコルを主に扱っており、これらは両方ともクエリ要素をサポートしています。HTTPは、URIクエリをどのように解釈しなければならないかに関しては何も述べません。RTSPは、解釈をRTSPサーバーに委ねており、現時点ではフラグメントとクエリ識別子には明確な定義の意味がないと明確に述べています。

URIの仕様であるRFC 3986では、一般的に、URI内のデータはユーザ・エージェントと1つ以上のサーバーの両方によって解析されることが多いと述べられています。これは、次のとおり、特に7.3項のHTTPを参照しています。

「例えば、HTTPでは、典型的なユーザ・エージェントは、URIを5つの主要要素へと解析し、そのオーソリティのサーバーにアクセスし、オーソリティ、パス、クエリの要素内のデータを送信するだろう。典型的なサーバーは、その情報を受信し、パスをセグメントへ、クエリをキー/値の対へと解析し、リクエストに応答するために実装固有のハンドラーを呼び出すだろう。」

クエリ要素の解釈はサーバーの機能次第であるため、クエリ要素に関するこのドキュメントの目的は、URIクエリによるメディア・フラグメントの指定に用いる標準的な名前―値の対の形式を推奨することです。サーバーとサーバー型ソフトウェアの提供者が、使用している既存のスキームをメディア資源と調和させ、この仕様で提案している命名法をサポートすることを推奨します。

3 URIフラグメントとURIクエリ

メディア・フラグメントを指定するためには、フラグメント情報を伝える方法を見つける必要があります。この仕様は、URI RFC 3986を基にしています。すべてのURIは、次の4つの部分で構成されると定義されています。

<スキーム名> : <階層部分> [ ? <クエリ> ] [ # <フラグメント> ]

したがって、URIで指定してメディア・フラグメントを表わす場合は、URIのクエリの部分またはURIのフラグメントの部分の2つの可能性があります。

3.1 どのような場合にURIフラグメントを選択する? どのような場合にURIクエリを選択する?

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

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

この仕様には、異なる種類のメディア・フラグメントの指定方法があります。メディア・フラグメントのユースケースと要件のドキュメント(「メディア・コンテナ/資源の適合条件」の項)で言及しているように、すべてのコンテナ形式とコーデックが、異なる種類のフラグメントURIのサポートに「適合する」とは限りません。「適合性」は、構文要素の変更やビットストリームのトランスコーディングなしに一次資源からメディア・フラグメントを抽出できるという事実と関係があります。

したがって、「適合する」資源は、URIフラグメントで指定できます。「条件付きで適合する」資源は、変更された構文要素を検索する追加の検索を実行することにより、URIフラグメントで指定できますが、コーデックのデータはそのままの状態となります。「適合しない」資源には、トランスコーディングが必要です。そのようなトランスコーディングを行ったメディア・フラグメントは、URIフラグメントではなく、URIクエリのみで指定できます。

したがって、URIのメカニズムでメディア・フラグメントを指定する際には、作者は、そのメディア・フラグメントが、トランスコーディングなしに(一次)資源自身から作成できるのか、トランスコーディングが必要なのかを知っている必要があります。後者の場合、唯一の選択肢は、URIクエリを用いること、そして、クエリを満たすためにトランスコーディングと(一次)派生資源の配信をサポートしているサーバーを用いることです。

3.2 ユーザ・エージェント内の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スムーズ・ストリーミングの場合に当てはまります。

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

メディア・フラグメント構文をネイティブにサポートしているけれども、独自のシーク方式を用いなければならないユーザ・エージェントの場合、補完的な仕様により、バイト・オフセットをより効果的にシークできる最適化を行うことができます。これには、別のメディア・フラグメント1.0 URI(高度)のドキュメントで定義されているプロトコルにユーザ・エージェントが従う適合サーバーが必要で、その場合、ユーザ・エージェントは、メディア・フラグメントのアドレス自身にバイト範囲のマッピングを行って、適切なバイト範囲を返すことをサーバーに要求します。この方法は、URIでは行えず、プロトコル・ヘッダーを追加して行う必要があります。このプロトコルに従うために適合サーバーとのインタラクションを行うユーザ・エージェントは、適切なバイト範囲を直接受信するため、不経済なネットワークのシークを行う必要はありません。

3.3 URIクエリの解決

説明した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クエリを実行するために、新しいプロトコル・ヘッダーは必要ありません。このドキュメントの後半で、情報交換を向上させるいくつかのオプションのプロトコル・ヘッダーを推奨します。

3.4 URIフラグメントとURIクエリの組み合わせ

メディア・フラグメントのためにURIフラグメントをURIクエリと組み合わせると、新しく作成された資源上でURIフラグメント解決が生じます。クエリ部分を持つURIでは新しい資源が作成されるため、新しい資源にフラグメント・オフセットを実行する必要があります。これは、単にURIの標準であるRFC 3986に準拠した行為です。

例えば、http://www.example.org/video.ogv?t=60,100#t=20は、60秒から始まって100秒まで進行する新しい資源に適用される20秒のフラグメント・オフセットになります。したがって、これに対する応答は、20秒のオフセットで再生が始まる40秒間の資源です。

4 メディア・フラグメント構文

この項では、メディア・フラグメント(MF)識別子の構文表現と、それをどのように解釈すべきかを説明します。メディア・フラグメント構文の定義の指針は次のとおりです。

  • a. クエリとフラグメントのMF構文は同一であるべきである。
  • b. MF構文は、明確であるべきである。
  • c. MF構文では、それが必要な次元に対して、あらゆるUTF-8文字が認められるべきである。
  • d. MF構文は、適用可能な公式標準に準拠すべきである。
  • e. MF構文は、クエリとフラグメントのデファクトの用法に準拠すべきである。
  • f. MF構文はできる限り簡潔であるべきである。

4.1 一般的な構造

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

名前と値は、UTF-8でエンコードされ、RFC 3986にしたがってパーセント・エンコードされた任意のUnicodeの文字列でありえます。一般的な構造を示すために、ここでは、フラグメント要素に名前―値の対を持つURIの例をいくつか示します。

http://www.example.com/example.ogv#t=10,20
http://www.example.com/example.ogv#track=audio&t=10,20
http://www.example.com/example.ogv#id=Cap%C3%ADtulo%202
		

任意の名前―値の対はこの方法でエンコードできますが、この仕様では、次元の固定セットを定義しています。次元のキーワード名は名前要素でエンコードされ、次元固有の構文は値要素でエンコードされます。

5.1.1 名前―値要素の処理の項では、名前―値の対の構文を処理して名前―値のUnicode文字列の対のリストにする方法をより詳細に定義しています。4.2 フラグメント次元の構文定義は、このUnicode文字列に適用されます。

4.2 フラグメント次元

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

時間(temporal)

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

空間(spatial)

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

メディア・フラグメントは、次の2つの追加の次元に沿ったメディアの指定をサポートしています(メディア・フラグメント1.0 URI(高度)で定義されている高度バージョン)。

トラック(track)

この次元は、「英語の音声と動画のトラック」などの、元のメディア内の1つ以上のトラックを表わします。

ID(id)

この次元は、「2章」などの、元のメディア内の名前付き時間フラグメントを表わし、時間フラグメントを指定するための便利な方法と見なすことができます。

すべての次元は、論理的に独立しており、組み合わせることができます。その結果は、次元の順序に依存しません。しかし、id次元は、時間次元の省略表現であり、両方の次元の組み合わせは、6.2.1 一般的なURIレベルのエラーの項で説明しているとおりに扱う必要があります。track次元は、(内蔵されている可能性がある)情報源メディアの部分(例えば「CDの音声トラック2」)ではなく、一式の並列するメディア・ストリームのうちの1つ(例えば「動画に対する英語の音声トラック」)を意味します。

4.2.1 時間次元

時間のクリッピングは、tという名前で表わされ、開始時間と終了時間(または、動画編集用語のインポイント (in-point)とアウトポイント(out-point))との間隔として指定されます。一方または両方のパラメータを省略でき、開始時間のデフォルトは0秒に、終了時間のデフォルトは情報源メディアの時間長に設定されます。間隔は半開(half-open)で、開始時間はその間隔の一部とみなされるのに対し、終了時間はその間隔の一部ではない最初の時点であるとみなされます。1つの数のみが示されていて、その前にコンマがなければ、開始時間に該当します(前にコンマがある場合は、終了時間を示す)。

例:

t=10,20   # => は、 [10,20) という時間間隔になる
t=,20     # => は、 [0,20) という時間間隔になる
t=10      # => は、 [10,end) という時間間隔になる

時間のクリッピングは、RFC 2326のNPT(Normal Play Time)で指定されます。これは、SMPTEタイムコードSMPTEや、メディア・フラグメント1.0 URI(高度)のドキュメントで記述されている高度なバージョンの実世界の計時時刻(計時)RFC 2326でも指定できます。開始・終了時間は、常に同じ形式で指定されます。形式は、名前で指定され、その後にコロン(:)が続き、npt:がデフォルトです。このバージョンのメディア・フラグメント仕様には、時間形式指定子を追加するための拡張メカニズムはありません。

NPTは、秒で指定でき、ミリ秒を示すためにオプションとして小数部を持つこともできます。または、コロンで区切った時、分、秒(同様に、オプションの小数部も可)で指定できます。分と秒は、正確に2桁の数字で指定しなければならず、時と秒の小数部は任意の桁数にすることができます。NPTの時、分、秒の仕様は、便宜的なものに過ぎず、フレームの精度を示すものではありません。NPTがデフォルトの時間スキームであるため、「npt:」識別子の指定はオプションです。この仕様は、NPT RFC 2326のRTSP仕様に基づいています。

npt-sec       =  1*DIGIT [ "." *DIGIT ]                     ; 定義は
npt-hhmmss    =  npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; RFC 2326から取った
npt-mmss      =  npt-mm ":" npt-ss [ "." *DIGIT] 
npt-hh        =   1*DIGIT     ; 任意の正の数
npt-mm        =   2DIGIT      ; 0-59
npt-ss        =   2DIGIT      ; 0-59

npttimedef    = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )

deftimeformat = %x6E.70.74                                  ; 「npt」
npttime       = npt-sec / npt-mmss / npt-hhmmss

例:

t=npt:10,20         # => [10,20) という時間間隔になる
t=npt:,121.5        # => [0,121.5) という時間間隔になる
t=0:02:00,121.5     # => [120,121.5) という時間間隔になる
t=npt:120,0:02:01.5 # => [120,121.5) という時間間隔になる

4.2.2 空間次元

空間のクリッピングは、ビジュアルなメディア・ストリームからピクセル領域を選択します。このバージョンのメディア・フラグメント仕様では、矩形の選択のみをサポートしています。矩形は、ピクセル座標またはパーセンテージで指定できます。

ピクセル座標は、資源に用いられている形式の定義に従って、資源の次元、アスペクト比、クリーン・アパーチャ、解像度などを考慮して解釈されます。アナモフィックな形式が、動画データの次元にアスペクト比を適用して「正しい」次元を得る方法を定義していない場合、ユーザ・エージェントは、1つの次元を追加し、他の次元を変えずにその比率を適用しなければなりません。

矩形選択は、xywhという名前で表わされます。その値は、pixel:またはpercent:というオプション形式で(デフォルトはpixel)、4つのコンマ区切りの整数です。整数はそれぞれ、x、y、幅、高さを示し、x = 0、y = 0は画像の左上隅です。パーセントを用いた場合、xと幅は、元のメディアの幅のパーセンテージであると解釈され、yと高さは、元の高さのパーセンテージであると解釈されます。

例:

xywh=160,120,320,240        # => x=160 で y=120 の位置の 320x240 の四角形になる
xywh=pixel:160,120,320,240  # => x=160 で y=120 の位置の 320x240 の四角形になる
xywh=percent:25,25,50,50    # => x=25% で y=25% の位置の 50%x50% の四角形になる

クリッピング領域がピクセル・ベースで、画像がマルチ解像度(ICOファイルのように)である場合、urlが画像全体を表わすように、フラグメントを無視しなければなりません(MUST)。より一般的には、1つの明確に定義されたピクセル解像度(幅と高さ)を持たない画像のピクセル・クリップは推奨されません。

5 メディア・フラグメントの処理

この項では、3 URIフラグメントとURIクエリの項で説明したHTTPプロトコル上の状況に関する様々な交換シナリオを定義します。

4 メディア・フラグメント構文の項で定義している形式文法は、メディア・フラグメントの生成機能が何を出力すべきかを記述するものです。これは、RFC 3986によって有効なパーセント・エンコーディングの可能性を考慮しておらず、文法はメディア・フラグメントの解析方法の仕様ではありません。そのため、5.1 メディア・フラグメントURIの処理の項では、メディア・フラグメントURIの解析方法を定義しています。

5.1 メディア・フラグメントURIの処理

この項では、4 メディア・フラグメント構文の項で定義しているメディア・フラグメントURIの解析方法を、知っているべき注意事項に関するいくつかの注とともに定義しています。実装者はあらゆる同等の技術を自由に用いることができます。

5.1.1 名前―値要素の処理

この項では、(URIのクエリまたはフラグメント要素の)オクテット列(octet string)を名前―値のUnicode文字列の対のリストに変換する方法を定義しています。

  1. namevalues構文に従ってオクテット列を解析し、名前と値の両方がオクテット列である名前―値の対のリストを作成します。RFC 3986に従い、パーセント・エンコードされたオクテットがデコードされる前に、名前と値の要素を解析し、分離しなければなりません。

  2. 名前―値の対ごとに、

    1. RFC 3986で定義されているとおりに、名前と値のパーセント・エンコードされたオクテットをデコードします。名前か値のいずれかが、パーセント・エンコードされた有効な文字列でない場合は、名前―値の対をリストから削除します。

    2. 名前と値をUTF-8として解釈し、Unicode文字列に変換します。名前か値のいずれかが、有効なUTF-8文字列でない場合は、名前―値の対をリストから削除します。

インプットがどのようなものであっても、アウトプットは明確に定義されることに注意してください。

例:

インプット アウトプット 説明
"t=1" [("t", "1")] シンプルなケース
"t=1&t=2" [("t", "1"), ("t", "2")] 名前の繰り返し
"a=b=c" [("a", "b=c")] 値の中に「=」
"a&b=c" [("a", ""), ("b", "c")] 値なし
"%74=%6ept%3A%310" [("t", "npt:10")] 不要なパーセント・エンコーディング
"id=%xy&t=1" [("t", "1")] 無効なパーセント・エンコーディング
"id=%E4r&t=1" [("t", "1")] 無効なUTF-8

この項で定義している処理は、多くのHTTPサーバー環境におけるURIクエリ要素の解析との互換性が高くなるように設計されていますが、下記の、実装者が知っているべき、互換性のない相違点が存在しています。

  • 「&」は名前―値の対の唯一の主要な区切り文字ですが、一部のサーバー・サイドの言語は「;」も区切り文字として扱います。

  • 無効なパーセント・エンコーディングを持つ名前―値の対は無視すべきですが、一部のサーバー・サイドの言語はそのようなエラーを黙って覆い隠します。

  • 「+」文字は特別な扱いをすべきではありませんが、一部のサーバー・サイドの言語はそれを空白(「 」)文字に置き換えます。

  • 同じ名前が複数存在する場合は保持しなければなりませんが、一部のサーバー・サイドの言語は最後の存在のみを保持します。

5.1.2 名前―値リストの処理

この項では、名前―値Unicode文字列の対のリストをメディア・フラグメントの次元に変換する方法を定義しています。

4.2 フラグメント次元の項で定義されている次元を前提とすると、名前と値の要素のそれぞれに対応する対の生成規則がそれぞれにあります。

キーワード 次元
t 4.2.1 時間次元
xywh 4.2.2 空間次元
track メディア・フラグメント1.0 URI(高度)
id メディア・フラグメント1.0 URI (高度)
  1. 最初は、すべての次元が未定義です。

  2. 名前―値の対ごとに、

    1. 名前が上記の表のキーワードと一致している場合は、対応する項に従って値を解釈します。

    2. そうでない場合は、名前―値の対はメディア・フラグメントの次元を表わしません。検証ソフトは警告を出すべきです。ユーザ・エージェントはその名前―値の対を無視しなければなりません。

注:名前―値の対は順に処理されるため、用いられるのは、最後の有効な次元です。

6 メディア・フラグメント・セマンティクス

この項では、メディア・フラグメントURIがユーザ・エージェントにどのように解釈されるべきかを論じます。有効な場合とエラーの場合を示します。エラーの場合には、メディア・フラグメントURIのみに基づいて検出できるエラーと、ユーザ・エージェントがメディア資源の情報(メディア資源の時間長など)を持っている場合のみに検出できるエラーとを区別しています。

6.1 有効なメディア・フラグメントURI

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

6.1.1 有効な時間次元

様々なケースの時間メディア・フラグメントについて説明するために、次の定義を作成しました。

  • s: メディアの開始時点であり、常に0(NPTで)
  • e: メディアの終了時点(つまり、時間長)であり、e > 0
  • a: 正の整数であり、a >= 0
  • b: 正の整数であり、b >= 0

さらに、4.2.1 時間次元の項で述べているとおり、時間間隔は、半開(つまり、開始時間はその間隔の一部とみなされるのに対し、終了時間はその間隔の一部ではない最初の時点であるとみなされる)です。したがって、以下で「メディアはxからyまで再生される」と述べている場合、yと一致するフレームは再生されないことを意味します。

t=a,bであり、a <= bの場合、次の時間フラグメントが有効です。

  • t=aであり、a < e: メディアは、aからeまで再生される。
  • t=,bであり、b <= e: メディアは、sからbまで再生される。
  • t=,bであり、e < b: メディアは、sからeまで再生される。
  • t=a,bであり、a = 0、b = e: メディア資源の全てが再生される。
  • t=a,bであり、a < b、a < e、b <= e: メディアは、aからbまで再生される(正常な事例)。
  • t=a,bであり、a < b、a < e、e < b: メディアは、aからeまで再生される。
  • %74=10,20は、パーセント・エンコードをt=10,20に解決する。
  • t=%31%30は、パーセント・エンコードをt=10に解決する。
  • t=10%2C20は、パーセント・エンコードをt=10,20に解決する。
  • t=%6ept:10は、パーセント・エンコードをt=npt:10に解決する。
  • t=npt%3a10は、パーセント・エンコードをt=npt:10に解決する。

6.1.2 有効な空間次元

様々なケースの空間メディア・フラグメントについて説明するために、次の定義を作成しました。

  • a: 空間領域(a >= 0)のx座標
  • b: 空間領域(b >= 0)のy座標
  • c: 空間領域(c > 0)の幅
  • d: 空間領域(d > 0)の高さ
  • w: メディア資源(w > 0)の幅
  • h: メディア資源(h > 0)の高さ

次の空間フラグメントが有効です。

  • xywh=a,b,c,dであり、a+c <= wかつb+d <= h: ユーザ・エージェントは、a,b,c,dという座標(ピクセルxywh形式)を持つ空間フラグメントを表示する(正常なピクセルの事例)。
  • xywh=a,b,c,dであり、a+c > w、a < wかつb+d < h: ユーザ・エージェントは、a,b,w-a,dという座標(ピクセルxywh形式)を持つ空間フラグメントを表示する。
  • xywh=a,b,c,dであり、a+c < w、b+d > hかつb < h: ユーザ・エージェントは、a,b,c,h-dという座標(ピクセルxywh形式)を持つ空間フラグメントを表示する。
  • xywh=a,b,c,dであり、a+c > w、a < w、b+d > hかつb < h: ユーザ・エージェントは、a,b,w-a,h-dという座標(ピクセルxywh形式)を持つ空間的フラグメントを表示する。
  • xywh=pixel:a,b,c,dであり、a+c <= wかつb+d <= h: ユーザ・エージェントは、a,b,c,dという座標(ピクセルxywh形式)を持つ空間フラグメントを表示する(正常なピクセルの事例)。
  • xywh=percent:a,b,c,dであり、a+c <= 100、b+d <= 100: ユーザ・エージェントは、floor(a/w*100)、floor(b/h*100)、ceil(c/w*100)、ceil(d/h*100)という座標(ピクセルxywh形式)の空間フラグメントを表示します(正常なパーセントの事例)。

複数の動画トラックを有するメディア資源の空間をクリッピングすると、空間のクリッピングはすべてのトラックに適用されます。

6.2 URI構文に基づいて発見可能なエラー

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

6.3 元のメディアの情報に基づいて発見可能なエラー

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

6.3.2 時間次元のエラー

様々なケースの時間メディア・フラグメントについて説明するために、6.1.1 有効な時間次元の定義を用います。下記の時間フラグメントの無効性は、ユーザ・エージェントが(存在しない時間的フラグメントの)元のメディアの時間長とフレーム・レートを知っている場合にのみ検出できます。

  • t=a,bであり、a > 0、a < b、a >= eかつb > e: 存在しない時間フラグメントで、ユーザ・エージェントは、メディアの終了eをシークする。
  • t=aであり、a >= e: 存在しない時間フラグメントで、ユーザ・エージェントは、メディアの終了eをシークする。

6.3.3 空間次元のエラー

様々なケースの空間メディア・フラグメントについて説明するために、6.1.2 有効な空間次元の定義を用います。下記の空間フラグメントの無効性は、ユーザ・エージェントが元のメディアの解像度を知っている場合にのみ検出できます。

  • xywh=a,b,c,dであり、a >= wかつ/またはb >= h: 矩形の左上の座標(a,b)が元のメディアの外部にあるため、無効。ユーザ・エージェントは、この空間フラグメントを無視すべき(SHOULD)。

7 実装者に対する注(非規範的)

この項には、実装者に対する注が含まれています。ここの情報の一部は、このドキュメントの他の部分ですでに正式に述べており、ここでの参照は主に注意喚起のためです。その他の項目は、実際にはこの仕様の範囲外ですが、ここの注は、作者が考える優れた実践を反映しています。

小項目は互いに排他的ではありません。したがって、メディア・フラグメントのクライアントとしてのウェブ・ブラウザの実装者は、7.1 メディア・フラグメント表示用ブラウザ7.2 クライアント表示用メディア・フラグメント、および7.3 すべてのメディア・フラグメントのクライアントの項を読むべきです。

7.1 メディア・フラグメント表示用ブラウザ

4.2.2 空間次元の項で定義しているピクセル座標は、HTML5で定義されている本来の幅と高さと同じであることを目指しています。空間URIフラグメントに関しては、次の項で、強調、切り取りという2つ別のユースケースについて説明します。しかし、HTMLを表示するクライアントは、切り取りを、デフォルトの表示メカニズムとして実装しているものと予想されます。

7.2 メディア・フラグメント表示用クライアント

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

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

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

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

7.3 すべてのメディア・フラグメントのクライアント

解決の順序: 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秒で停止すべきです。

7.4 メディア・フラグメント・サーバー

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

7.5 メディア・フラグメント・ウェブ・アプリケーション

メディア・フラグメント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でスクロール機能を手動で実装する必要があります。

A 参考文献

[RFC 2119]
S. Bradner. Key Words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.
[RFC 2326]
Real Time Streaming Protocol (RTSP). IETF RFC 2326, April 1998. Available at http://www.ietf.org/rfc/rfc2326.txt.
[RFC 2327]
Session Description Protocol (SDP). IETF RFC 2327, April 1998. Available at http://www.ietf.org/rfc/rfc2327.txt.
[RFC 2616]
Hypertext Transfer Protocol -- HTTP/1.1. IETF RFC 2616, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt.
[RFC 3339]
G. Klyne and C. Newman. Date and Time on the Internet: Timestamps. IETF RFC 3339, July 2002. Available at http://www.ietf.org/rfc/rfc3339.txt.
[RFC 3533]
The Ogg Encapsulation Format Version 0. IETF RFC 3533, May 2003. Available at http://www.ietf.org/rfc/rfc3533.txt.
[RFC 3986]
T. Berners-Lee and R. Fielding and L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. IETF RFC 3986, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt.
[RFC 5234]
D. Crocker. Augmented BNF for Syntax Specifications: ABNF. IETF RFC 5234, January 2008. Available at http://tools.ietf.org/html/rfc5234.
[RFC 4288]
N. Freed and J. Klensin. Media Type Specifications and Registration Procedures. IETF RFC 4288, December 2005. Available at http://www.ietf.org/rfc/rfc4288.txt.
[RFC 5147]
E. Wilde and M. Duerst. URI Fragment Identifiers for the text/plain Media Type. IETF RFC 5147, April 2008. Available at http://tools.ietf.org/html/rfc5147.
[HTML 4.0]
D. Ragett and A. Le Hors and I. Jacobs. HTML Fragment identifiers. W3C Recommendation, December 1999. Available at http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri.
[HTML 5]
Ian Hickson. HTML5. W3C Working Draft, May 2011. Available at http://www.w3.org/TR/2011/WD-html5-20110525/.
[SVG 1.1]
J. Ferraiolo.Linking into SVG content: IRI fragments and SVG views. W3C Recommendation, August 2011. Available at http://www.w3.org/TR/2011/REC-SVG11-20110816/linking.html#LinksIntoSVG.
[SMIL]
Sjoerd Mullender. Synchronized Multimedia Integration Language (SMIL 3.0). W3C Recommendation, December 2008. Available at http://www.w3.org/TR/2008/REC-SMIL3-20081201/.
[xpointer]
P. Grosso and E. Maler and J. Marsh and N. Walsh. XPointer Framework. W3C Recommendation, March 2003. Available at http://www.w3.org/TR/xptr-framework/.
[MPEG-7]
Information Technology - Multimedia Content Description Interface (MPEG-7). Standard No. ISO/IEC 15938:2001, International Organization for Standardization(ISO), 2001.
[temporal URI]
S. Pfeiffer and C. Parker and A. Pang. Specifying time intervals in URI queries and fragments of time-based Web resources. Internet Draft, March 2005. Available at http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html.
[CMML]
Continuous Media Markup Language (CMML), Version 2.1. Internet-Draft, March 2006 http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt.
[ROE]
Rich Open multitrack media Exposition (ROE). Xiph Wiki. Available at http://wiki.xiph.org/index.php/ROE.
[Skeleton]
Ogg Skeleton. Xiph Wiki. Available at http://wiki.xiph.org/OggSkeleton.
[MPEG-21]
Information Technology - Multimedia Framework (MPEG-21). Standard No. ISO/IEC 21000:2002, International Organization for Standardization(ISO), 2002. Available at http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip.
[SMPTE]
SMPTE RP 136 Time and Control Codes for 24, 25 or 30 Frame-Per-Second Motion-Picture Systems
[ISO Base Media File Format]
Information technology - Coding of audio-visual objects - Part 12: ISO base media file format. Available at http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip
[Use cases and requirements for Media Fragments]
Use cases and requirements for Media Fragments. W3C Working Draft, December 2009. Available at http://www.w3.org/TR/2009/WD-media-frags-reqs-20091217
[Media Fragments 1.0 URI (advanced)]
Media Fragments 1.0 URI (advanced). W3C Working Draft, December 2011. Available at http://www.w3.org/TR/2011/WD-media-frags-recipes-20111201/
[UTF-8]
UTF-8, a transformation format of ISO 10646. Available at http://tools.ietf.org/html/rfc3629
[ECMA-262 5th edition]
ECMA-262 5th edition. Available at http://www.ecma-international.org/publications/standards/Ecma-262.htm
[Media Annotations]
API for Media Resource 1.0. W3C Candidate Recommendation, November 2011. Available at http://www.w3.org/TR/2011/CR-mediaont-api-1.0-20111122/
[Web Linking]
Web Linking. Internet Draft, May 2010. Available at http://tools.ietf.org/html/draft-nottingham-http-link-header-10

B URIに関するABNF構文のまとめ(非規範)

unichar       = <any Unicode code point>
unistring     = *unichar

; defined in RFC 5234
ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT         =  %x30-39 ; 0-9
HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

; defined in RFC 3986
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment      = *( pchar / "/" / "?" )

; defined in RFC 2326
npt-sec       = 1*DIGIT [ "." *DIGIT ]                     ; definitions taken
npt-hhmmss    = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from RFC 2326
npt-mmss      = npt-mm ":" npt-ss [ "." *DIGIT] 
npt-hh        =   1*DIGIT     ; any positive number
npt-mm        =   2DIGIT      ; 0-59
npt-ss        =   2DIGIT      ; 0-59

; defined in RFC 3339
date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

; Mediafragment definitions
segment       = mediasegment / *( pchar / "/" / "?" )     ; augmented fragment
                                                          ; definition taken from
                                                          ; RFC 3986

;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Common Prefixes ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;

deftimeformat    = %x6E.70.74                                      ; "npt"
pfxdeftimeformat = %x74.3A.6E.70.74                                ; "t:npt"
smpteformat      = %x73.6D.70.74.65                                ; "smpte"
                  / %x73.6D.70.74.65.2D.32.35                      ; "smpte-25"
                  / %x73.6D.70.74.65.2D.33.30                      ; "smpte-30"
                  / %x73.6D.70.74.65.2D.33.30.2D.64.72.6F.70       ; "smpte-30-drop"
pfxsmpteformat   = %x74.3A.73.6D.70.74.65                          ; "t:smpte"
                  / %x74.3A.73.6D.70.74.65.2D.32.35                ; "t:smpte-25"
                  / %x74.3A.73.6D.70.74.65.2D.33.30                ; "t:smpte-30"
                  / %x74.3A.73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "t:smpte-30-drop"
clockformat      = %x63.6C.6F.63.6B                                ; "clock"
pfxclockformat   = %x74.3A.63.6C.6F.63.6B                          ; "clock"

;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
mediasegment      = ( timesegment / spacesegment / tracksegment / idsegment )
               *( "&" ( timesegment / spacesegment / tracksegment  / idsegment )

timesegment      = timeprefix "=" timeparam
timeprefix       = %x74                                      ; "t"
timeparam        = npttimedef / smptetimedef / clocktimedef
npttimedef       = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )

npttime       = npt-sec / npt-mmss / npt-hhmmss

smptetimedef  = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
frametime     = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]

clocktimedef  = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
clocktime     = (datetime / walltime / date)
datetime      = date-time                                 ; inclusion of RFC 3339

spacesegment  = xywhprefix   "=" xywhparam
xywhprefix    = %x78.79.77.68                             ; "xywh"
xywhparam     = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
xywhunit      = %x70.69.78.65.6C                          ; "pixel"
              / %x70.65.72.63.65.6E.74                    ; "percent"

tracksegment  = trackprefix "=" trackparam
trackprefix   = %x74.72.61.63.6B                          ; "track"
trackparam    = unistring

idsegment   = idprefix "=" idparam
idprefix    = %x69.64					                  ; "id"
idparam     = unistring
      

C 謝辞(非規範的)

このドキュメントは、W3C Media Fragments Working Groupの作業の成果です。ワーキンググループのメンバー(執筆時点でアルファベット順に記述)は、Eric Carlson (Apple, Inc.),、Chris Double (Mozilla Foundation)、Michael Hausenblas (DERI Galway at the National University of Ireland, Galway, Ireland)、Jack Jansen (CWI)、Philip Jagenstedt (Opera Software)、Yves Lafon (W3C)、Erik Mannens (IBBT)、Thierry Michel (W3C/ERCIM), Guillaume (Jean-Louis) Olivrin (Meraka Institute)、Soohong Daniel Park (Samsung Electronics Co., Ltd.)、Conrad Parker (W3C Invited Experts)、Silvia Pfeiffer (W3C Invited Experts)、Nobuhisa Shiraishi (NEC Corporation)、David Singer (Apple, Inc.)、Thomas Steiner (Google, Inc.)、Raphael Troncy (EURECOM)、Davy Van Deursen (IBBT)です。

discussions on public-media-fragment@w3.orgでの議論に貢献いただいた方々にも感謝を表わします。特に、Olivier Aubert、Werner Bailer、Tobias Burger、Pierre-Antoine Champin、Cyril Concolato、Fantasai、Franck Denoual、Martin J. Durst、Jean Pierre Evain、Ken Harrenstien、Kilroy Hughes、Ryo Kawaguchi、Wim Van Lancker、Veronique Malaise、Henrik Nordstrom、Christoph Paper、Yannick Prie、Yves Raimond、Julian Reschke、Geoffrey Sneddon、Felix Sasaki、Jakub Sendor、Philip Taylor、Christian Timmerer、Jorrit Vermeiren、Jeroen Wijering、Munjo Yu、Boris Zbarsky。