MF

There is another page with same name:
Edit New

媒体素片 (URL)

[5] 媒体素片 (Media Fragments) は、動画や音声の一部を識別するための素片識別子の構文です。

仕様書

[93] に基本部分に絞ってW3C勧告になったものの、 その後メンテナンスもされずに放置されています。

意味

[79] 媒体素片は、媒体の時間的・空間的な位置や範囲を表します。

MPD Anchor

[68] MPEG-DASH (ISO/IEC 23009-1) の C.4 には MPEG DASH (application/dash+xml) の素片識別子である MPD Anchor の定義があります。

[76] MPD Anchor は実質的に媒体素片の独自拡張ですが、なぜか t= の値を除きすべて独自に規定しています。

[77] MPD Anchor は、表現開始する時刻と状態を表します >>78。

構文

[25] 媒体素片は、名前と値を = で連結した組を1つ以上 & で区切ったリストです。ただし = と値なしで名前だけの組も含められます。 >>24

媒体素片
  1. 名前と値
  2. *
    1. &
    2. 名前と値
名前と値
  1. 名前
  2. ?
    1. =
    2. 値

[26] 名前と値は、任意の Unicode 文字列を UTF-8 で符号化し、パーセント符号化したものです。 ただし名前に & と = を使うことはできず、 値に & を使うことはできません。 >>24

[27] RFC 3986 が参照されており >>24、 URI で使えない文字はパーセント符号化しなければならず、 それ以外はパーセント符号化してもしなくても良いと思われます。
[28] & や = を名前や値に含めたい時は、 パーセント符号化すれば良いようです。
[46] 名前や値の部分には : のような記号が含まれることもありますが、 それも含めてパーセント符号化してもしなくても同義であり、 どちらも妥当 (valid) です >>45。

[29] 名前は次元を表し、値はそれに対応する値を表します。 値の構文は、次元の規定によります。 >>24

[80] MPD Anchor はなぜか本文で , 区切りと規定していますが、 仕様書中の例はすべて & を使っています。
[81] MPD Anchor は = で名前と値を区切ること以外ほとんど何も規定していません (それでも MPEG DASH は国際標準です)。

構文解析

[34] 媒体素片を解釈する場合には、 URL の一部として与えられたオクテット列を & によって区切ったリストとして分割し、 その各要素を = によって区切った名前と値の組として分割し、 名前と値をそれぞれパーセント復号します。 >>33

[36] = が複数あれば、最初のもので分割します。 また = がなければ、値なしとします。
[37] & だけが区切りであり、 ; は区切りではありません。また + は 0x20 ではありません。

[35] ただし = で分割した名前と値がパーセント符号化されたオクテット列として正しくない場合や、 パーセント復号した結果が UTF-8 で復号できない場合には、 その名前と値の組は無視します。 >>33

[38] 同じ名前がリスト中に複数含まれることもあります。
[83] MPD Anchor は構文解析の方法を規定していません。

次元

[30] 次元 (dimension) は媒体素片において一部分を選択する観点を表しています。 次元は互いに論理的に独立しており、組み合わせることができます >>24。 次元の順序に関わらず、得られる結果は同じです >>24。

[44] t と id が共に時間次元を表すなど、 例外はあります。

[31] 次の次元があります。

[82] 媒体素片本体仕様では t=, xywh= が定義されています。
[69] MPD Anchor では t=, period=, as=, track= が定義されています >>78。

[41] 同じ次元を複数指定することは禁止されていません。 利用者エージェントは最後の指定を使うべきです >>45, >>33。 それ以外は妥当であれ非妥当であれ、無視するべきです >>45。

[48] ただし例外的に track= は複数指定できます >>45。 (track= 参照。)

[42] 未対応の次元がある場合、利用者エージェントは無視しなければなりません。 検証器は警告するべきです。 >>33

[47] 利用者エージェントは、未知の次元の指定を無視するべきです >>45。

[49] >>42 と >>47 が同じ意図の規定なのかどうか不明です。 >>47 はなぜか SHOULD でしかありません。

[50] 適用対象のMIME型が分かっていれば、次元の存在に関する妥当性を判断できます。 静止画に対する時刻の指定のように当該媒体に存在しない次元が指定されていれば、 その次元の指定は無視するべきです >>45。

[51] 各次元ごとに構文と意味、処理方法の規定があります。 ある次元の指定が妥当でなければ、無視されることがあります。 (しかしそれだけによって媒体素片全体が無視されるわけではありません。)

各次元の項を参照。
[54] 値は妥当なものと誤り (error) のものがあります。 どう処理するかはそれぞれ規定されていますが、基本的には無視されます。 誤りには構文的なものや機械的に決定できるものもあれば、 当該媒体の情報を得ていないと誤っているか判断のつかないもの (例えば媒体の長さより大きな値を指定したエラー) があります。

MIME 型

[8] 媒体素片が適用される対象となるMIME型について、 媒体素片仕様書は、各MIME型の仕様が採用することを推奨 (recommend) >>9 するにとどめており、実際に特定の MIME型に適用できるとはしていません。

[10] audio/*, image/*, video/* のMIME型は媒体素片を採用することを推奨 (recommend) されています >>9。

[66] 実際上は媒体要素の実装で t= が使われていますから、 媒体要素で利用されるMIME型に関しては媒体素片が採用されていると言えます。

[84] application/dash+xml は MPD Anchor を採用しています >>78。ただし MPD Anchor は媒体素片とはされていません (実質的には媒体素片ですが)。

query での利用

[12] 媒体素片は素片識別子だけでなく、query として使うこともできます。 しかし一般に HTTP や RTSP では query は鯖が任意の方法で解釈することとなっており、 媒体素片の仕様も query で用いることを強制はしていません。 鯖は媒体素片と既存の query とを調和させることを推奨 (recommend) される >>11 にとどまっています。

[16] 媒体素片によって表される資源の部分の中には、 包含子の形式とコーデックに依存して「なじむ (fit) 」 ものとそうでないものがあります。ここで「なじむ」とは、 元の資源の構文要素を変更したり、ビット列を転符号化したりせずに求める部分を取り出せることをいいます。 >>13

[17] 「なじむ」ものは素片識別子によって表すこともできますが、 「なじまない」ものは query によって表すしかありません >>13。 query によって指定された場合は、鯖が適宜符号化し直すなどして求める部分を返すことになります。

処理

[14] 媒体素片の素片識別子の適用後の素片と元の資源は同じ MIME型であるべきです >>13。

[15] 例えば動画のうちの1つのフレームを識別する媒体素片によって得られるのは静止画ではなく、 フレームが1つの動画であるべきです >>13。

[18] 媒体素片が素片識別子として指定された場合、 利用者エージェントは元の資源を取得し、 そこから媒体素片で指定された部分を取り出すこととなります。 利用者エージェントの機能と資源の形式次第では、 元の資源の必要となる範囲を特定してそこだけ鯖から取得することができるかもしれません。 また、媒体素片を鯖に送信して処理を委ねる方法を用意することも想定はされています >>13 (が実際にはありません)。

[19] 例えば動画形式によっては動画上の範囲とバイト範囲との対応関係の索引データが含まれていて、 それに従い範囲要求を使って必要な部分だけ取得できるかもしれません >>13。

[22] 媒体素片が query として指定された場合、 鯖は元の資源から媒体素片で指定された部分を取り出し、 必要な変換を施して新しい資源として利用者エージェントに返すこととなります >>13。バイト列として一部分を取り出すだけでは不十分で、 当該データ形式において適切な形式で完全な資源として、 必要なら再符号化も行った上で返すことになります。

[23] 例えば 30s から 70s までの範囲のような媒体素片が指定されたとしても、 返される資源の開始位置は 0s で終了位置は 40s になります。 また新しい資源と元の資源の関係は明確にはなっていません。 >>13 ですから通常は指定範囲の外にシークすることもできません。 データ形式によっては、あるいはプロトコルの拡張によって元の資源との関係や元の資源における新しい資源の範囲がどこであるかを明示できるかもしれません >>13 が、媒体素片の仕様の範囲ではそのような仕組みは用意されていないようです。

[39] 媒体素片は、構文解析した後、リストに含まれる各名前と値の組を、 名前によって示された次元の仕様に基づき、指定された順に解釈します >>33。

[40] 同じ次元が複数指定された場合には、最後の指定が最終的に有効になります >>33。

[53] 次元ごとに処理の方法やエラーの場合に無視することが規定されています。

[52] 各次元の項も参照。

[32] 次元によっては、条件次第で媒体素片全体を無視するよう求めている場合があります。

xywh 参照。

[56] t=, id=, track= の選択をまず container のレベルで行い、次に xywh= の選択を codec のレベルで行うことが期待されています >>55。

[60] HTML Standard は媒体要素の処理の方法を規定していますが、 媒体の URL に指定が含まれる場合にそれに従ってトラックを選択したり、 開始時刻を決定したりしても良いと規定しており、 そのような指定の例として媒体素片を挙げています。

[57] 媒体素片が指定された URL が埋め込まれる場面のマーク付け言語などの側でも範囲の選択の指定がある場合にどう処理するべきかは、 埋め込まれる場面の側で規定するべきである >>55 として、媒体素片としては決められていません。 しかし、一般に媒体素片を適用した結果が単独の媒体である場合のように更に場面側の指定を適用するのがよい >>55 旨の記載もあります。

例

[85] MPD Anchor の例 >>78

42nd minute of Period1

my.mpd# t=42&period=Period1

空白はママ

42nd minute from the start of the presentation, English 5.1 audio and video

my.mpd#t=42&track=en51&track=vid

Set of Adaptation Sets from starting from the start of Period1

my.mpd#period=Period1&group=123

[74] MPD Anchor の例 >>73

#period=programme_part_2&t=50:00

歴史

[1] W3C Media Fragments Working Group ( 版) <http://www.w3.org/2008/WebVideo/Fragments/>

[2] Use cases and requirements for Media Fragments ( 版) <http://www.w3.org/TR/2009/WD-media-frags-reqs-20090430/>

[6] Media Fragments URI 1.0 ( 版) <http://www.w3.org/TR/2009/WD-media-frags-20091217/>

[20] IRC logs: freenode / #whatwg / 20091229 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20091229>

[63] Media Fragments URI 1.0 ( 版) <http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/>

[61] Bug 12425 – User interface of temporal media fragment URI in @src of video element ( 版) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=12425>

[65] Media Fragments URI 1.0 Implementation Report ( 版) <http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-impl/>

[3] Media Fragments URI 1.0 (basic) ( 版) <http://www.w3.org/TR/2012/REC-media-frags-20120925/>

[58] Errata in Media Fragments URI 1.0 (basic) ( 版) <http://www.w3.org/2008/WebVideo/Fragments/errata/media-frags-20120925-errata>

[21] Re: is spec complete? ( (Silvia Pfeiffer 著, 版)) <http://lists.w3.org/Archives/Public/public-media-fragment/2013Jun/0002.html>

[43] 次の機能は「basic」には含まれず、未完成のまま放置されています。

[59] 完全には削除されず、中途半端な規定がなぜか残っています。 こんな品質でも W3C勧告になってしまうのですから、不思議なものです。

[7] Bug 23492 – Linking to a page with a fragment identifier that causes a particular media element to be shown and to seek to a particular position ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23492>

[72] MPD Anchor は >>70, >>71, >>73, >>75 から参照されています。

[67] Specifying time intervals in URI queries and fragments of time-based Web resources ( ( 版)) <http://annodex.net/TR/URI_fragments.html#rfc.section.4>

[86] oaubert/mediafragment-prototype ( 版) <https://github.com/oaubert/mediafragment-prototype>

Dynamic Media Fragment

This is a proposal for dynamic spatial media fragments, as well as arbitrary shaped spatial media fragments, for highlighting moving areas in videos.

[87] Arbitrarily Shaped and Dynamic Spatial Media Fragments ( 版) <http://olivieraubert.net/dynamic-media-fragments/>

[88] Re: Informal (dynamic) Media Fragments URI discussion (Olivier Aubert 著, 版) <https://lists.w3.org/Archives/Public/public-media-fragment/2015Jun/0000.html>

[89] Informal (dynamic) Media Fragments URI discussion (Thomas Steiner 著, 版) <https://lists.w3.org/Archives/Public/public-media-fragment/2015May/0000.html>

[90] 24910 – Define how Media Fragments URI end position is handled ( 版) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24910>

[91] Podlove Deep Linking | Podlove ( 版) <http://podlove.org/deep-link/>

The Media Fragments [1]specification requires the media fragment specifier to be a parameter following a hash sign (“#”) and allows for additional parameters to be passed along. As the podcast client is expected to add just the time range information, any additional parameters that your web player might need must be included in the URL stated in the feed following the fragment identifier.

The Podcast Client MUST honor existing parameters and append the time specification with an ampersand sign (“&”) if a parameter already exists. The following URL

http://mypodcast.com/episode/player.php?episode=23#style=external

must be extended as described to look something like this:

http://mypodcast.com/episode/player.php?episode=23#style=external&t=10,200

Right now, this specification does not define any other parameters but might in do so in a future version.

[92] Errata in Media Fragments URI 1.0 (basic) ( ()) <https://www.w3.org/2008/WebVideo/Fragments/errata/media-frags-20120925-errata>

[94] Video and audio APIs - Learn web development | MDN ( ()) <https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Video_and_audio_APIs#Specifying_playback_range>

The playback range portion of the media element URI specification was added to Gecko 9.0 (Firefox 9.0 / Thunderbird 9.0 / SeaMonkey 2.6). At this time, this is the only part of the Media Fragments URI specification implemented by Gecko, and it can only be used when specifying the source for media elements, and not in the address bar.

[95] Support for MPD Anchors · Issue #1361 · Dash-Industry-Forum/dash.js () <https://github.com/Dash-Industry-Forum/dash.js/issues/1361>

[96] ODRL Vocabulary & Expression 2.2 () <https://w3c.github.io/poe/vocab/#term-absoluteTemporalPosition>

The fragment part of a Media Fragment URI (https://www.w3.org/TR/media-frags/) may be used for the right operand.

Updated: