index.html
124 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-us"><head><title>Media Fragments URI 1.0</title><style type="text/css">
/**/
code { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; }
ol.enumla { list-style-type: lower-alpha; }
ol.enumlr { list-style-type: lower-roman; }
ol.enumua { list-style-type: upper-alpha; }
ol.enumur { list-style-type: upper-roman; }
dt.label { display: run-in; }
li, p { margin-top: 0.3em;
margin-bottom: 0.3em; }
.diff-chg { background-color: yellow; }
.diff-del { background-color: red; text-decoration: line-through;}
.diff-add { background-color: lime; }
table { empty-cells: show; }
table caption {
font-weight: normal;
font-style: italic;
text-align: left;
margin-bottom: .5em;
}
div.issue {
color: red;
}
.rfc2119 {
font-variant: small-caps;
}
div.exampleInner pre { margin-left: 1em;
margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
border-top-width: 4px;
border-top-style: double;
border-top-color: #d3d3d3;
border-bottom-width: 4px;
border-bottom-style: double;
border-bottom-color: #d3d3d3;
padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
margin: 4px}
div.boxedtext {
border: solid #bebebe 1px;
margin: 2em 1em 1em 2em;
}
span.practicelab {
margin: 1.5em 0.5em 1em 1em;
font-weight: bold;
font-style: italic;
}
span.practicelab { background: #dfffff; }
span.practicelab {
position: relative;
padding: 0 0.5em;
top: -1.5em;
}
p.practice
{
margin: 1.5em 0.5em 1em 1em;
}
@media screen {
p.practice {
position: relative;
top: -2em;
padding: 0;
margin: 1.5em 0.5em -1em 1em;
}
}
/**/ </style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" />
</head>
<body><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p>
<h1><a id="title" name="title" />Media Fragments URI 1.0</h1>
<h2><a id="w3c-doctype" name="w3c-doctype" />W3C Working Draft 13 April 2010</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2010/WD-media-frags-20100413">http://www.w3.org/TR/2010/WD-media-frags-20100413</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/media-frags">http://www.w3.org/TR/media-frags</a>
</dd><dt>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2009/WD-media-frags-20091217">http://www.w3.org/TR/2009/WD-media-frags-20091217</a>
</dd><dt>Editors:</dt><dd><a href="http://www.eurecom.fr/~troncy/">
Raphaël Troncy
</a>, EURECOM</dd><dd><a href="http://multimedialab.elis.ugent.be/emannens">
Erik Mannens
</a>, IBBT Multimedia Lab, University of Ghent</dd><dt>Contributors:</dt><dd><a href="http://www.deri.ie/about/team/member/Michael_Hausenblas/">
Michael Hausenblas
</a>, DERI, National University of Ireland, Galway</dd><dd><a href="mailto:philipj@opera.com">
Philip Jägenstedt
</a>, Opera Software</dd><dd><a href="http://www.cwi.nl/~jack/">
Jack Jansen
</a>, Center for Mathematics and Computer Science (CWI Amsterdam)</dd><dd><a href="http://www.w3.org/People/Lafon/">
Yves Lafon
</a>, W3C</dd><dd><a href="http://www.kfish.org/">
Conrad Parker
</a>, W3C Invited Expert</dd><dd><a href="http://blog.gingertech.net/">
Silvia Pfeiffer
</a>, W3C Invited Expert</dd><dd><a href="http://multimedialab.elis.ugent.be/dvdeurse">
Davy Van Deursen
</a>, IBBT Multimedia Lab, University of Ghent</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2010 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr /><div>
<h2><a id="abstract" name="abstract" />Abstract</h2><p>
This document describes the Media Fragments 1.0 specification. It specifies the syntax for constructing media fragment URIs and explains how to handle them when used over the HTTP protocol. The syntax is based on the specification of particular field-value pairs that can be used in URI fragment and URI query requests to restrict a media resource to a certain fragment.
</p></div><div>
<h2><a id="status" name="status" />Status of this Document</h2><p><em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest revision
of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p><p>This is the Second Public Working Draft of the Media Fragments URI 1.0 specification. It has been
produced by the <a href="http://www.w3.org/2008/WebVideo/Fragments/">Media
Fragments Working Group</a>, which is part of the
<a href="http://www.w3.org/2008/WebVideo/">W3C Video on the Web Activity</a>.</p><p>Please send comments about this document to <a href="mailto:public-media-fragment@w3.org">public-media-fragment@w3.org</a>
mailing list (<a href="http://lists.w3.org/Archives/Public/public-media-fragment/">public
archive</a>).</p><p>
Publication as a Working Draft does not imply endorsement by the
W3C Membership. This is a draft document and may be updated,
replaced or obsoleted by other documents at any time. It is
inappropriate to cite this document as other than work in
progress.
</p><p>
This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">
5 February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/42785/status">public
list of any patent disclosures</a> made in connection with the
deliverables of the group; that page also includes instructions
for disclosing a patent. An individual who has actual knowledge
of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
6 of the W3C Patent Policy</a>.
</p></div><div class="toc">
<h2><a id="contents" name="contents" />Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
2 <a href="#standardisation">Standardisation Issues</a><br />
2.1 <a href="#standardisation-terminology">Terminology</a><br />
2.2 <a href="#standardisation-approach">Media Fragments Standardisation</a><br />
2.2.1 <a href="#standardisation-URI-fragments">URI Fragments</a><br />
2.2.2 <a href="#standardisation-URI-queries">URI Queries</a><br />
3 <a href="#fragment-query">URI fragment and URI query</a><br />
3.1 <a href="#URIquery-vs-fragments">When to choose URI fragments? When to choose URI queries?</a><br />
3.2 <a href="#URIfragment-user-agent">Resolving URI fragments within the user agent</a><br />
3.3 <a href="#URIfragment-server">Resolving URI fragments with server help</a><br />
3.4 <a href="#URIfragment-proxies">Resolving URI fragments in a proxy cacheable manner</a><br />
3.5 <a href="#URIquery-media-fragments">Resolving URI queries</a><br />
3.6 <a href="#URIquery-URIfragment">Combining URI fragments and URI queries</a><br />
4 <a href="#media-fragment-syntax">Media Fragments Syntax</a><br />
4.1 <a href="#general-structure">General Structure</a><br />
4.1.1 <a href="#processing-name-value-components">Processing name-value components</a><br />
4.1.2 <a href="#processing-name-value-lists">Processing name-value lists</a><br />
4.2 <a href="#url-serialization">URL Serialization</a><br />
4.3 <a href="#fragment-dimensions">Fragment Dimensions</a><br />
4.3.1 <a href="#naming-time">Temporal Dimension</a><br />
4.3.1.1 <a href="#npt-time">Normal Play Time (NPT)</a><br />
4.3.1.2 <a href="#smpte-time">SMPTE time codes</a><br />
4.3.1.3 <a href="#clock-time">Wall-clock time code</a><br />
4.3.2 <a href="#naming-space">Spatial Dimension</a><br />
4.3.3 <a href="#naming-track">Track Dimension</a><br />
4.3.4 <a href="#naming-name">Named Dimension</a><br />
4.3.5 <a href="#common-syntax">Common Syntax</a><br />
5 <a href="#media-fragment-processing">Media Fragments Processing</a><br />
5.1 <a href="#processing-overview">Overview</a><br />
5.2 <a href="#processing-protocol-frag">Protocol for URI fragment Resolution in HTTP</a><br />
5.2.1 <a href="#processing-protocol-UA-mapped">UA mapped byte ranges</a><br />
5.2.1.1 <a href="#processing-protocol-UA-mapped-new">UA requests URI fragment for the first time</a><br />
5.2.1.2 <a href="#processing-protocol-UA-mapped-unchanged">UA requests URI fragment it already has buffered</a><br />
5.2.1.3 <a href="#processing-protocol-UA-mapped-changed">UA requests URI fragment of a changed resource</a><br />
5.2.2 <a href="#processing-protocol-Server-mapped">Server mapped byte ranges</a><br />
5.2.3 <a href="#processing-protocol-proxy">Proxy cacheable Server mapped byte ranges</a><br />
5.3 <a href="#processing-protocol-query">Protocol for URI query Resolution in HTTP</a><br />
6 <a href="#media-fragment-semantics">Media Fragments Semantics</a><br />
6.1 <a href="#error-general">Errors on the General URI level</a><br />
6.1.1 <a href="#error-general-non-existent">Non-existent dimension:</a><br />
6.1.2 <a href="#error-general-underspec">Under-specified Dimension</a><br />
6.2 <a href="#error-temporal">Errors on the temporal dimensions</a><br />
6.2.1 <a href="#error-temporal-valid">Validity error</a><br />
6.2.2 <a href="#error-temporal-non-existent">Non-existent</a><br />
6.2.3 <a href="#error-temporal-undefined">Undefined</a><br />
6.2.4 <a href="#error-temporal-empty">Empty</a><br />
6.2.5 <a href="#error-temporal-offset">Offset</a><br />
6.2.6 <a href="#error-temporal-non-error">Non-errors</a><br />
6.3 <a href="#error-spatial">Errors on the spatial dimensions</a><br />
6.4 <a href="#error-track">Errors on the track dimensions</a><br />
6.5 <a href="#error-named">Errors on the named dimensions</a><br />
7 <a href="#media-fragment-display">Displaying Media Fragments</a><br />
8 <a href="#conclusions">Conclusions</a><br />
8.1 <a href="#qualification-resources">Qualification of Media Resources</a><br />
</p>
<h3><a id="appendices" name="appendices" />Appendices</h3><p class="toc">A <a href="#references-normative">References</a><br />
B <a href="#collected-syntax">Collected ABNF Syntax</a> (Non-Normative)<br />
C <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br />
D <a href="#change-log">Change Log</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a id="introduction" name="introduction" />1 Introduction</h2><p>
Audio and video resources on the World Wide Web are currently treated as "foreign" objects, which can only be embedded using a plugin that is capable of decoding and interacting with the media resource. Specific media servers are generally required to provide for server-side features such as direct access to time offsets into a video without the need to retrieve the entire resource. Support for such media fragment access varies between different media formats and inhibits standard means of dealing with such content on the Web.
</p><p>
This specification provides for a media-format independent, standard means of addressing media fragments on the Web using Uniform Resource Identifiers (URI). In the context of this document, media fragments are regarded along three different dimensions: temporal, spatial, and tracks. Further, a fragment can be marked with a name and then addressed through a URI using that name. The specified addressing schemes apply mainly to audio and video resources - the spatial fragment addressing may also be used on images.
</p><p>
The aim of this specification is to enhance the Web infrastructure for supporting the addressing and retrieval of subparts of time-based Web resources, as well as the automated processing of such subparts for reuse. Example uses are the sharing of such fragment URIs with friends via email, the automated creation of such fragment URIs in a search engine interface, or the annotation of media fragments with RDF. Such use case examples as well as other side conditions on this specification and a survey of existing media fragment addressing approaches are provided in the requirements <cite><a href="#mf-req">Use cases and requirements for Media Fragments</a></cite> document that accompanies this specification document.
</p><p>
The media fragment URIs specified in this document have been implemented and demonstrated to work with media resources over the HTTP and RTP/RTSP protocols. Existing media formats in their current representations and implementations provide varying degrees of support for this specification. It is expected that over time, media formats, media players, Web Browsers, media and Web servers, as well as Web proxies will be extended to adhere to the full specification. This specification will help make video a first-class citizen of the World Wide Web.
</p></div><div class="div1">
<h2><a id="standardisation" name="standardisation" />2 Standardisation Issues</h2><div class="div2">
<h3><a id="standardisation-terminology" name="standardisation-terminology" />2.1 Terminology</h3><p>
The keywords <strong>MUST</strong>, <strong>MUST NOT</strong>, <strong>SHOULD</strong> and <strong>SHOULD NOT</strong> are to be interpreted as defined in <cite><a href="#rfc2119">RFC 2119</a></cite>.
</p><p>
According to <cite><a href="#rfc3986">RFC 3986</a></cite>, URIs that contain a fragment are actually not URIs, but URI references relative to the namespace of another URI. In this document, when the term 'media fragment URIs' is used, it actually means 'media fragment URI references'.
</p></div>
It should clearly
explain the state of standardisation of current URIs and that URI
fragment and query parameters are under the control of the mime type
owner or the server software respectively. And that this is a
recommendation for normalisation of the use of fragment and query
parameters related to media resources. It involves regarding fragment
and query values as strings of name-value pairs separated by "&",
which builds on existing CGI parameter conventions. Mime type owners
and server software developers are encouraged to use the
specifications of this document in their implementations.
<div class="div2">
<h3><a id="standardisation-approach" name="standardisation-approach" />2.2 Media Fragments Standardisation</h3><p>
The basis for the standardisation of media fragment URIs is the URI specification, <cite><a href="#rfc3986">RFC 3986</a></cite>. Providing media fragment identification information in URIs refers here to the specification of the structure of a URI fragment (anything behind a "#" in a URI) or a URI query (anything behind a "?" and before a "#" in a URI). This document will explain how URI fragments and URI queries are structured to identify media fragments. In this section, we look at implications of standardising their structure.
</p><div class="div3">
<h4><a id="standardisation-URI-fragments" name="standardisation-URI-fragments" />2.2.1 URI Fragments</h4><p>
The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says about the format of a URI fragment in Section 3.5:
</p><p>
<i>"The fragment's format and resolution is [..] dependent on the media type [RFC2046] of a potentially retrieved representation. [..] Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications."</i>
</p><p>
This essentially means that only media type definitions (as registered through the process defined in <cite><a href="#rfc4288">RFC 4288</a></cite>) are able to introduce a standard structure on URI fragments for that mime type. One part of the registration process of a media type can include information about how fragment identifiers in URIs are constructed for use in conjunction with this media type.
</p><p>
Note that the registration of URI fragment construction rules as expressed in Section 4.11 of <cite><a href="#rfc4288">RFC 4288</a></cite> is only a SHOULD-requirement. An analysis of all media type registrations showed that there is not a single media type registration in the audio/*, image/*, video/* branches that is currently defining fragments or fragment semantics.
</p><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>See also the <a href="http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview">review</a>.
</p>
</td></tr></table><p>
The Media Fragment WG has no authority to update registries of all targeted media types. To the best of our knowledge there are only few media types that actually have a specified fragment format even if it is not registered with the media type: these include Ogg, MPEG-4, and MPEG-21. Further, only a small number of software packages actually supports these fragment formats. For all others, the semantics of the fragment are considered to be unknown.
</p><p>
As such, the intention of this document is to propose a specification to all media type owners in the audio/*, image/*, and video/* branches for a structured approach to URI fragments and for specification of commonly agreed dimensions to address media fragments (i.e. subparts of a media resource) through URI fragments. We recommend media type owners to harmonize their existing schemes with the ones proposed in this document and update or add the fragment semantics specification to their media type registration.
</p></div><div class="div3">
<h4><a id="standardisation-URI-queries" name="standardisation-URI-queries" />2.2.2 URI Queries</h4><p>The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says about the format of a URI query in Section 3.4:
</p><p>
<i>"The query component [..] serves to identify a resource within the scope of the URI's scheme and naming authority (if any). [..] Query components are often used to carry identifying information in the form of "key=value" pairs [..]."</i>
</p><p>
URI query specifications are more closely linked to the URI scheme, some of which do not even use a query component. We are mostly concerned with the HTTP <cite><a href="#rfc2616">RFC 2616</a></cite> and the RTP/RTSP <cite><a href="#">rfc2326</a></cite> protocols here, which both support query components. HTTP says nothing about how a URI query has to be interpreted. RTSP explicitly says that fragment and query identifiers do not have a well-defined meaning at this time, with the interpretation left to the RTSP server.
</p><p>
The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says generally that the data within the URI is often parsed by both the user agent and one or more servers. It refers in particular to HTTP in Section 7.3:
</p><p>
<i>"In HTTP, for example, a typical user agent will parse a URI into its five major components, access the authority's server, and send it the data within the authority, path, and query components. A typical server will take that information, parse the path into segments and the query into key/value pairs, and then invoke implementation-specific handlers to respond to the request."</i>
</p><p>
Since the interpretation of query components resides with the functionality of servers, the intention of this document wrt query components is to recommend standard name-value pair formats for use in addressing media fragments through URI queries. We recommend server and server-type software providers to harmonize their existing schemes in use with media resources to support the nomenclature proposed in this specification.
</p></div></div></div><div class="div1">
<h2><a id="fragment-query" name="fragment-query" />3 URI fragment and URI query</h2><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">This section is non-normative</td></tr></table><p>
To address a media fragment, one needs to find ways to convey the fragment information. This specification builds on URIs <cite><a href="#rfc3986">RFC 3986</a></cite>. Every URI is defined as consisting of four parts, as follows:
</p><div class="exampleOuter"><p>
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
</p></div><p>
There are therefore two possibilities for representing the media fragment addressing in URIs: the <em>URI query part</em> or the <em>URI fragment part</em>.
</p><div class="div2">
<h3><a id="URIquery-vs-fragments" name="URIquery-vs-fragments" />3.1 When to choose URI fragments? When to choose URI queries?</h3><p>
For media fragment addressing, both approaches - URI query and URI fragment - are useful.
</p><p>
The main difference between a URI query and a URI fragment is that a URI query produces a new resource, while a URI fragment provides a secondary resource that has a relationship to the primary resource. URI fragments are resolved from the primary resource without another retrieval action. This means that a user agent should be capable to resolve a URI fragment on a resource it has already received without having to fetch more data from the server.
</p><p>
A further requirement put on a URI fragment is that the media type of the retrieved fragment should be the same as the media type of the primary resource. Among other things, this means that a URI fragment that points to a single video frame out of a longer video results in a one-frame video, not in a still image. To extract a still image, one would need to create a URI query scheme - something not envisaged here, but easy to devise.
</p><p>
There are different types of media fragment addressing in this specification. As noted in the <cite><a href="#mf-req">Use cases and requirements for Media Fragments</a></cite> document (section "Fitness Conditions on Media Containers/Resources"): not all container formats and codecs are "fit" for supporting the different types of fragment URIs. "Fitness" relates to the fact that a media fragment can be extracted from the primary resource without syntax element modifications or transcoding of the bitstream.
</p><p>
Resources that are "fit" can therefore be addressed with a URI fragment. Resources that are "conditionally fit" can be addressed with a URI fragment with an additional retrieval action that retrieves the modified syntax elements but leaves the codec data untouched. Resources that are "unfit" require transcoding. Such transcoded media fragments cannot be addressed with URI fragments, but only with URI queries.
</p><table border="1" summary="Editorial note: Raphael"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Raphael</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">I wonder if we should not paste here the table in the Annexe B of the requirement document with the various container formats and their "fit" value for the media fragment dimensions considered</td></tr></table><p>
Therefore, when addressing a media fragment with the URI mechanism, the author has to know whether this media fragment can be produced from the (primary) resource itself without any transcoding activities or whether it requires transcoding. In the latter case, the only choice is to use a URI query and to use a server that supports transcoding and delivery of a (primary) derivative resource to satisfy the query.
</p></div><div class="div2">
<h3><a id="URIfragment-user-agent" name="URIfragment-user-agent" />3.2 Resolving URI fragments within the user agent</h3><p>
A user agent may itself resolve and control the presentation of media fragment URIs. The simplest case arises where the user agent has
already downloaded the entire resource and can perform the extraction from its locally cached copy. For some media types, it may also be
possible to perform the extraction over the network without any special protocol assistance. For temporal fragments this requires a user
agent to be able to seek on the media resource using existing protocol mechanisms.
</p><p>
An example of a URI fragment used to address a media fragment is <code>http://www.example.org/video.ogv#t=60,100</code>. In this case,
the user agent knows that the primary resource is <code>http://www.example.org/video.ogv</code> and that it is only expected to display
the portion of the primary resource that relates to the fragment <code>#t=60,100</code>, i.e. seconds 60-100. Thus, the relationship
between the primary resource and the media fragment is maintained.
</p><p>
In traditional URI fragment retrieval, a user agent requests the complete primary resource from the server and then applies the
fragmentation locally. In the media fragment case, this would result in a retrieval action on the complete media resource, on which the
user agent would then locally perform its fragment extraction.
</p><p>
Media resources are not always retrieved over HTTP using a single request. They may be retrieved as a sequence of byte range requests
on the original resource URI, or may be retrieved as a sequence of requests to different URIs each representing a small part of the
media. The reasons for such mechanisms include bandwidth conservation, where a client chooses to space requests out over time during
playback in order to maximize bandwidth available for other activities, and bandwidth adaptation, where a client selects among various
representations with varying bitrate depending on the current bandwidth availability.
</p><p>
A user agent that knows how to map media fragments to byte ranges will be able to satisfy a URI fragment request such as the above example
by itself. This is typically the case for user agents that know how to seek to media fragments over the network.
For example, a user agent that deals with a media file that includes an index of its seekable structures can resolve the media fragment
addresses to byte ranges from the index. This is the case e.g. with seekable QuickTime files. Another example is a user agent that
knows how to seek on a media file through a sequence of byte range requests and eventually receives the correct media fragment. This is
the case e.g. with Ogg files in Firefox versions above 3.5.
</p><p>
Similarly, a user agent that knows how to map media fragments to a sequence of URIs can satisfy a URI fragment request by itself. This
is typically the case for user agents that perform adaptive streaming. For example, a user agent that deals with a media resource that
contains a sequence of URIs, each a media file of a few seconds duration, can resolve the media fragment addresses to a subsequence of
those URIs. This is the case with QuickTime adaptive bitrate streaming or IIS Smooth Streaming.
</p><p>
If such a user agent natively supports the media fragment syntax as specified in this document, it is deemed conformant to this
specification for fragments and for the particular dimension.
</p></div><div class="div2">
<h3><a id="URIfragment-server" name="URIfragment-server" />3.3 Resolving URI fragments with server help</h3><p>
For user agents that natively support the media fragment syntax, but have to use their own seeking approach, this specification provides
an optimisation that can make the byte offset seeking more efficient. It requires a conformant server with which the user agent will follow
a protocol defined later in this document.
</p><p>
In this approach, the user agent asks the server to do the byte range mapping for the media fragment address itself and send back the
appropriate byte ranges. This can not be done through the URI, but has to be done through adding protocol headers. User agents that
interact with a conformant server to follow this protocol will receive the appropriate byte ranges directly and will not need to do costly
seeking over the network.
</p><p>
Note that it is important that the server also informs the user agent what actual media fragment range it was able to retrieve. This is
important since in the compressed domain it is not possible to extract data at an arbitrary resolution, but only at the resolution
that the data was packaged in. For example, even if a user asked for <code>http://www.example.org/video.ogv#t=60,100</code> and the
user agent sent a range request of <code>t=60,100</code> to the server, the server may only be able to return the range
<code>t=58,103</code> as the closest decodable range that encapsulates all the required data.
</p><p>
Note that if done right, the native user agent support for media fragments and the improved server support can be integrated without
problems: the user agent just needs to include the byte range and the media fragment range request in one request. A server that does not
understand the media fragment range request will only react to the byte ranges, while a server that understands them will ignore the
byte range request and only reply with the correct byte ranges. The user agent will understand from the response whether it received a
reply to the byte ranges or the media fragment ranges request and can react accordingly.
</p></div><div class="div2">
<h3><a id="URIfragment-proxies" name="URIfragment-proxies" />3.4 Resolving URI fragments in a proxy cacheable manner</h3><p>
The current setup of the World Wide Web relies heavily on the use of caching Web proxies to speed up the delivery of content. In the
case of URI fragments that are resolved by the server as indicated in the previous section, existing Web proxies have no means of
caching these requests since they only understand byte ranges.
</p><p>
To make use of the existing Web proxy infrastructure of the Web, we need to make sure that the user agent only asks for byte ranges,
so they can be served from the cache. This is possible if the server - instead of replying with the actual data - replies with the mapped
byte ranges for the requested media fragment range. Then, the user agent is able to resend his range request this time with bytes only,
which can possibly already be satisfied from the cache. Details of this will be specified later.
</p><table border="1" summary="Editorial note: Raphael"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Raphael</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">Should we not foresee future "smart" media caches that would be able to actually cache range request in other units than bytes?
</td></tr></table></div><div class="div2">
<h3><a id="URIquery-media-fragments" name="URIquery-media-fragments" />3.5 Resolving URI queries</h3><p>
The described URI fragment addressing methods only work for byte-identical segments of a media resource, since we assume a simple mapping
between the media fragment and bytes that each infrastructure element can deal with. Where it is impossible to maintain byte-identity
and some sort of transcoding of the resource is necessary, the user agent is not able to resolve the fragmentation by itself and a
server interaction is required. In this case, URI queries have to be used since they result in a server interaction and can deliver a
transcoded resource.
</p><table border="1" summary="Editorial note: Raphael"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Raphael</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
Weak argument? I would rather argue that if we cannot maintain byte-identity, then the fragment part of a URI is simply not suitable per
TAG finding that we would need to request. The argument that the server has to do some complex processing seems to me weaker.
</td></tr></table><p>
Another use for URI queries is when a user agent actually wants to receive a completely new resource instead of just a byte range from
an existing (primary) resource. This is, for example, the case for playlists of media fragment resources. Even if a media fragment
could be resolved through a URI fragment, the URI query may be more desirable since it does not carry with itself the burden
of the original primary resource - its file headers may be smaller, its duration may be smaller, and it does not automatically allow
access to the remainder of the original primary resource.
</p><p>
When URI queries are used, the retrieval action has to additionally make sure to create a fully valid new resource. For example, for the
Ogg format, this implies a reconstruction of Ogg headers to accurately describe the new resource (e.g. a non-zero start-time or different
encoding parameters). Such a resource will be cached in Web proxies as a different resource to the original primary resource.
</p><p>
An example URI query that includes a media fragment specification is <code>http://www.example.org/video.ogv?t=60,100</code>. This results
in a video of duration 40s (assuming the original video was more than 100s long).
</p><p>
Note that this resource has no per-se relationship to the original primary resource. As a user agent uses such a URI with e.g. a HTML5
video element, the browser has no knowledge about the original resource and can only display this video as a 40s long video starting at 0s.
The context of the original resource is lost.
</p><p>
A user agent may want to display the original start time of the resource as the start time of the video in order to be consistent with the
information in the URI. It is possible to achieve this in one of two ways: either the video file itself has some knowledge that it is an
extract from a different file and starts at an offset - or the user agent is told through the retrieval action which original primary
resource the retrieved resource relates to and can find out information about it through another retrieval action. This latter option
will be regarded later in this document.
</p><p>
An example for a media resource that has knowledge about itself of the required kind are Ogg files. Ogg files that have a skeleton
track and were created correctly from the primary resource will know that their start time is not 0s but 60s in the above example.
The browser can simply parse this information out of the received bitstream and may display a timeline that starts at 60s and ends at 100s
in the video controls if it so desires.
</p><p>
Another option is that the browser parses the URI and knows about how media resources have a fragment specification that follows a standard.
Then the browser can interpret the query parameters and extract the correct start and end times and also the original primary resource.
It can then also display a timeline that starts at 60s and ends at 100s in the video controls. Further it can allow a right-click menu to
click through to the original resource if required.
</p><p>
A use case where the video controls may neither start at 0s nor at 60s is a mashed-up video created through a list of media fragment URIs.
In such a playlist, the user agent may prefer to display a single continuous timeline across all the media fragments rather than a
collection of individual timelines for each fragment. Thus, the 60s to 100s fragment may e.g. be mapped to an interval at 3min20 to 4min.
</p><p>
No new protocol headers are required to execute a URI query for media fragment retrieval. Some optional protocol headers that improve the
information exchange will be recommended later in this document.
</p></div><div class="div2">
<h3><a id="URIquery-URIfragment" name="URIquery-URIfragment" />3.6 Combining URI fragments and URI queries</h3><p>
A combination of a URI query for a media fragment with a URI fragment yields a URI fragment resolution on top of the newly created resource.
Since a URI with a query part creates a new resource, we have to do the fragment offset on the new resource. This is simply a conformant
behaviour to the URI standard <cite><a href="#rfc3986">RFC 3986</a></cite>.
</p><p>
For example, <code>http://www.example.org/video.ogv?t=60,100#t=20</code> will lead to the 20s fragment offset being applied to the new
resource starting at 60 going to 100. Thus, the reply to this is a 40s long resource whose playback will start at an offset of 20s.
</p><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
We should at the end of the document set up a table with all the different addressing types and http headers and say what we deem
is conformant and how to find out whether a server or user agent is conformant or not.
</td></tr></table></div></div><div class="div1">
<h2><a id="media-fragment-syntax" name="media-fragment-syntax" />4 Media Fragments Syntax</h2><p>
This section describes the external representation of a media fragment specifier, and how this should be interpreted.
</p><table border="1" summary="Editorial note: Jack"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Jack</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2"><ul><li>a. The MF syntax for queries and fragments should be identical</li><li>b. The MF syntax should be unambiguous</li><li>c. The MF syntax should allow any UTF-8 character in track or id names</li><li>d. The MF syntax should adhere to applicable formal standards</li><li>e. The MF syntax should adhere to de-facto usage of queries and fragments</li><li>f. The MF syntax should be as concise as possible, with no unneeded grammatical fluff</li></ul></td></tr></table><div class="div2">
<h3><a id="general-structure" name="general-structure" />4.1 General Structure</h3><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">This section is ready to implement.</td></tr></table><table border="1" summary="Editorial note: Yves"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Yves</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">To check and rephrase</td></tr></table><table border="1" summary="Editorial note: Raphael"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Raphael</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">To generate a simple figure that shows this processing:
URI parsing (percent decoding) => name=value pairs => (rfc2047encoding) HTTP</td></tr></table><p>
The fragment identifier consists of a list of name/value pairs, the
dimension specifiers, separated by the primary separator
<code>&</code>. Name and value are separated by an equal
sign (<code>=</code>).
</p><div class="exampleInner"><a id="namevalues-prod" name="namevalues-prod" /><pre>
namevalues = namevalue *( "&" namevalue )
namevalue = name [ "=" value ]
name = fragment - "&" - "="
value = fragment - "&"
</pre></div><p>Here are some examples of URIs with name-value pairs, to
demonstrate the general structure:</p><div class="exampleInner"><pre>
http://www.example.com/example.ogv#a=b&c=d
http://www.example.com/example.ogv#t=10,20
http://www.example.com/example.ogv#track=audio
http://www.example.com/example.ogv#track=audio&t=10,20</pre></div><p>
This is the pseudo-code translation of the ABNF syntax. Implementors are free to use any equivalent technique(s).
</p><div class="div3">
<h4><a id="processing-name-value-components" name="processing-name-value-components" />4.1.1 Processing name-value components</h4><p>
This section defines how to parse an octet string into an
ordered list of name-value pairs of unicode strings.
The octet string consists of name-value pairs separated by
the "&" character.
</p><p id="parse-a-name-value-component">
To <b>parse a name-value component</b>, perform the
following steps:
</p><ol class="enumar"><li>
Let <var>input</var> be the octet string to be parsed.
</li><li>
Let <var>pairs</var> be a list of 2-tuples, initially empty.
</li><li>
For each octet string <var>name-value</var>
in <var>input</var> delimited by and not including
"&", the beginning of <var>input</var> and the end
of <var>input</var>, in the order they appear
in <var>input</var>, perform the following steps:
<ol class="enumla"><li>
Let <var>pct-name</var> be longest substring from the
beginning of <var>name-value</var> that does not
include "=".
</li><li>
Let <var>pct-value</var> be the substring from after
the first "=" in <var>name-value</var> to the end
of <var>name-value</var>, or the empty string
if <var>name-value</var> does not include "=".
</li><li>
Let <var>name</var> and <var>value</var> be the
result of
<a title="" href="#decode-a-percent-encoded-string">
decoding
percent-encoding
</a> of <var>pct-name</var>
and <var>pct-value</var> respectively. If either
decoding fails, skip the following step.
</li><li>
Append the 2-tuple
(<var>name</var>, <var>value</var>)
to <var>pairs</var>.
</li></ol></li><li>
Return <var>pairs</var>.
</li></ol><p id="decode-a-percent-encoded-string">
To <b>decode a percent-encoded string</b>, perform
the following steps:
</p><ol class="enumar"><li>
Let <var>input</var> be the string to be decoded.
</li><li>
Let <var>reserved</var> be the empty string.
</li><li>
Let <var>output</var> be the result of calling
Decode(<var>input</var>, <var>reserved</var>).
If <b>URIError</b> was thrown, abort these steps;
decoding fails. <cite><a href="#ecma-262">ECMA-262 5th edition</a></cite></li><li>
Return <var>output</var>.
</li></ol><p>
Note that when <a title="" href="#parse-a-name-value-component">
parsing a
name-value component
</a>,the output is well defined for any input.
Examples:
</p><table border="1"><tr><th>input</th><th>output</th><th>comments</th></tr><tr><td>"t=1"</td><td>[("t", "1")]</td><td>simple case</td></tr><tr><td>"t=1&t=2"</td><td>[("t", "1"), ("t", "2")]</td><td>repeated name</td></tr><tr><td>"a=b=c"</td><td>[("a", "b=c")]</td><td>"=" in value</td></tr><tr><td>"a&b=c"</td><td>[("a", ""), ("b", "c")]</td><td>missing value</td></tr><tr><td>"%74=%6ept%3A%310"</td><td>[("t", "npt:10")]</td><td>unnecssary percent-encoding</td></tr><tr><td>"id=J%E4genstedt&t=1"</td><td>[("t", "1")]</td><td>invalid percent-encoding (not UTF-8)</td></tr></table><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>
While the algorithms defined in this section are designed
to be largely compatible with the parsing of the URI query
component in many HTTP server environments, there are
incompatible differences that implementors should be aware
of:
</p>
<ul><li>
"&" is the only primary separator for name-value
pairs, but some server-side languages also treat ";" as
a separator.
</li><li>
name-value pairs with invalid percent-encoding should be
ignored, but some server-side languages silently mask
such errors.
</li><li>
The "+" character should not be treated specially, but
some server-side languages replace it with a space (" ")
character.
</li><li>
Multiple occurrences of the same name must be preserved,
but some server-side languages only preserve the last
occurrence.
</li></ul>
</td></tr></table></div><div class="div3">
<h4><a id="processing-name-value-lists" name="processing-name-value-lists" />4.1.2 Processing name-value lists</h4><p>
This section defines how to convert an ordered list of
name-value pairs of unicode strings into a set of media
fragment dimensions.
</p><p id="convert-name-value-pairs">
To <b>
convert a name-value list into a set of media
fragment dimensions
</b>, perform the following steps:
</p><ol class="enumar"><li>
Let <var>input</var> be the ordered list of name-value
pairs to be converted.
</li><li>
Let <var>dimensions</var> be a set of dimensions,
initially empty.
</li><li>
For each pair (<var>name</var>, <var>value</var>)
in <var>input</var>, perform the following steps:
<ol class="enumla"><li>
If <var>name</var> is a valid production of
the <a href="#">timeprefix</a> syntax
and <var>value</var> is a valid production of
the <a href="#">timeparam</a> syntax, perform
the following steps, let the temporal dimension
of <var>dimensions</var> be the time range represented
by <var>value</var> (it is an error if a value was previously set).
</li><li>
If <var>name</var> is a valid production of
the <a href="#">xywhprefix</a> syntax
and <var>value</var> is a valid production of
the <a href="#">xywhparam</a> syntax, perform
the following steps, let the spatial dimension
of <var>dimensions</var> be the area represented
by <var>value</var> (it is an error if a value was previously set).
</li><li>
If <var>name</var> is a valid production of
the <a href="#">trackprefix</a> syntax
and <var>value</var> is a valid production of
the <a href="#">trackparam</a> syntax,
perform the following steps, let the track dimension
of <var>dimensions</var> be the track represented
by <var>value</var> (it is an error if a value was previously set).
</li><li>
If <var>name</var> is a valid production of
the <a href="#">nameprefix</a> syntax
and <var>value</var> is a valid production of
the <a href="#">nameparam</a> syntax, perform
the following steps, let the named dimension
of <var>dimensions</var> be the name represented
by <var>value</var> (it is an error if a value was previously set).
</li><li>
Otherwise, this is a invalid name-value pair per this
specification. Validators must emit an error.
</li></ol></li><li>
Return <var>dimensions</var>.
</li></ol></div></div><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>
Can we please indicate that a name-value pair that does not fit this specification isn't invalid, but has to be parsed according to another specification. I don't think it should be an error to have such a name-value pair in the URL. It should be noted that it may further restrict the data that is returned for the URL.
</p>
</td></tr></table><div class="div2">
<h3><a id="url-serialization" name="url-serialization" />4.2 URL Serialization</h3><p>
This ABNF syntax defines the structure of media fragment URI components. A
specification of the parsing algorithm to extract these from an actual URI
can be found in <a href="#processing-name-value-components"><b>4.1.1 Processing name-value components</b></a> and
<a href="#processing-name-value-lists"><b>4.1.2 Processing name-value lists</b></a>. Note that the URI works on
octet strings, but the parsed name-value pairs are unicode strings, since
percent-encoding is resolved. The following definitions apply to
these unicode strings.
</p><p>Media fragments support fragmenting the media along four dimensions:</p><dl><dt class="label">temporal</dt><dd><p>
This dimension denotes a specific time range in the
original media, such as "starting at second 10, continuing
until second 20";
</p></dd><dt class="label">spatial</dt><dd><p>
this dimension denotes a specific range of pixels in
the original media, such as "a rectangle with size (100,100)
with its top-left at coordinate (10,10)";
</p></dd><dt class="label">track</dt><dd><p>
this dimension denotes one track (media type) in the
original media, such as "the english audio track";
</p></dd><dt class="label">named</dt><dd><p>
this dimension denotes a named section of the original
media, such as "chapter 2".
</p></dd></dl><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>
The track dimension refers to one of a set of parallel media streams (e.g. "the english audio track for a video"),
not to a (possibly self-contained) section of the source media (e.g. "Audio track 2 of a CD"). The self-contained
section is handled by the named dimension.
</p>
</td></tr></table><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>
The name dimension cannot be combined with the other
dimensions, because the semantics depend on the
underlying source media format: some media formats
support naming of temporal extents, others support
naming of groups of tracks, etc. Error semantics are
discussed in
<a href="#media-fragment-semantics"><b>6 Media Fragments Semantics</b></a>.
</p>
</td></tr></table><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>
The temporal, spatial and track dimensions are logically
independent and can be combined; the outcome is
independent of the order of the dimensions.
</p>
</td></tr></table><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>
A general URI fragment or query string specified on a
media resource may contain several field-value pairs. They
are not restricted to the ones specified here, since
applications may want to use additional other parameters
to communicate further requests to custom servers.
</p>
</td></tr></table><table border="1" summary="Editorial note: Philip"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Philip</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>
We need to decide what do with this and validity. One
suggested option has been to require non-MF extensions
to use a vendor prefix.
</p>
</td></tr></table><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>
A conformant server or user agent will need to be able to
parse a random URI query or fragment string for a media
resource and identify the relevant parts. E.g. the
relevant field-value pair out of a media fragment URI like
this <code>http://www.example.com/video.ogv#&&=&=tom;jerry=&t=34&t=meow:0#</code>
is <code>t=34</code>. Detailed conformance requirements
are given in the following sections.
</p>
</td></tr></table></div><div class="div2">
<h3><a id="fragment-dimensions" name="fragment-dimensions" />4.3 Fragment Dimensions</h3><div class="div3">
<h4><a id="naming-time" name="naming-time" />4.3.1 Temporal Dimension</h4><p>
Temporal clipping is denoted by the name <code>t</code>, and specified as an interval with a begin time and an end time (or an in-point and an out-point, in video editing terms). Either or both may be omitted, with the begin time defaulting to 0 seconds and the end time defaulting to the duration of the source media. The interval is half-open: the begin time is considered part of the interval whereas the end time is considered to be the first time point that is not part of the interval. If a single number only is given, this is the begin time.
</p><div class="exampleInner"><a id="timesegment" name="timesegment" /><pre>
timeprefix = %x74 ; "t"
timeparam = <a href="#npttimedef">npttimedef</a> / <a href="#smptetimedef">smptetimedef</a> / <a href="#clocktimedef">clocktimedef</a>
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
t=10,20 # => results in the time interval [10,20)
t=,20 # => results in the time interval [0,20)
t=10, # => results in the time interval [10,end)
t=10 # => also results in the time interval [10,end)</pre></div><p>
Temporal clipping can be specified either as Normal Play Time (npt) <cite><a href="#rtsp">RFC 2326</a></cite>, as SMPTE timecodes, <cite><a href="#smpte">SMPTE</a></cite>, or as real-world clock time (clock) <cite><a href="#rtsp">RFC 2326</a></cite>. Begin and end times are always specified in the same format. The format is specified by name, followed by a colon (<code>:</code>), with <code>npt:</code> being the default.
</p><p>
In this version of the media fragments specification there is no extensibility mechanism to add time format specifiers.
</p><div class="div4">
<h5><a id="npt-time" name="npt-time" />4.3.1.1 Normal Play Time (NPT)</h5><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>This section (and everything from 4.2 and 4.1 that is required to implement it) is ready to implement.</p>
</td></tr></table><p>
Normal Play Time can either be specified as seconds, with an optional fractional part to indicate seconds, or as colon-separated hours, minutes and seconds (again with an optional fraction). Minutes and seconds must be specified as exactly two digits, hours and fractional seconds can be any number of digits. The hours, minutes and seconds specification for NPT is a convenience only, it does not signal frame accuracy. The specification of the "npt:" identifier is optional since NPT is the default time scheme. This specification builds on the RTSP specification of NPT <cite><a href="#rtsp">RFC 2326</a></cite>.
</p><div class="exampleInner"><a id="npttimedef" name="npttimedef" /><pre>
npt-sec = 1*DIGIT [ "." *DIGIT ] ; definitions taken
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from <cite><a href="#rtsp">RFC 2326</a></cite>
npt-hh = 1*DIGIT ; any positive number
npt-mm = 2DIGIT ; 0-59
npt-ss = 2DIGIT ; 0-59
npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( "," npttime )
deftimeformat = %x6E.70.74 ; "npt"
npttime = npt-sec / npt-hhmmss
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
t=npt:10,20 # => results in the time interval [10,20)
t=npt:120, # => results in the time interval [120,end)
t=npt:,121.5 # => results in the time interval [0,121.5)
t=0:02:00,121.5 # => results in the time interval [120,121.5)
t=npt:120,0:02:01.5 # => also results in the time interval [120,121.5)</pre></div></div><div class="div4">
<h5><a id="smpte-time" name="smpte-time" />4.3.1.2 SMPTE time codes</h5><p>
SMPTE time codes are a way to address a specific frame (or field) without running the risk of rounding errors causing a different frame to be selected. The format is always colon-separated hours, minutes, seconds and frames. Frames are optional, defaulting to 00. If the source format has a further subdivison of frames (such as odd/even fields in interlaced video) these can be specified further with a number after a dot (<code>.</code>). The SMPTE format name must always be specified, because the interpretation of the fields depends on the format. The SMPTE formats supported in this version of the specification are:
</p><ul><li><code>smpte</code>,</li><li><code>smpte-25</code>,</li><li><code>smpte-30</code> and </li><li><code>smpte-30-drop</code>.</li></ul><p>
<code>smpte</code> is a synonym for <code>smpte-30</code>.
</p><div class="exampleInner"><a id="smptetimedef" name="smptetimedef" /><pre>
smptetimedef = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
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"
frametime = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
t=smpte-30:0:02:00,0:02:01:15 # => results in the time interval [120,121.5)
t=smpte-25:0:02:00:00,0:02:01:12.1 # => results in the time interval [120,121.5)</pre></div><p>
Using SMPTE timecodes may result in frame-accurate begin and end times, but only if the timecode format used in the media fragment specifier is the same as that used in the original media item.
</p></div><div class="div4">
<h5><a id="clock-time" name="clock-time" />4.3.1.3 Wall-clock time code</h5><p>
Wall-clock time codes are a way to address real-world clock time that is associated with a typically live video stream. These are the same time codes that are being used by RTSP <cite><a href="#rtsp">RFC 2326</a></cite>, by SMIL <cite><a href="#smil30">SMIL</a></cite>, and by HTML5 <cite><a href="#html5">HTML 5</a></cite>. The scheme uses ISO 8601 UTC timestamps (http://www.iso.org/iso/date_and_time_format). The format separates the date from the time with a "T" character and the string ends with "Z", which includes time zone capabilities. To that effect, the ABNF grammar is referring to <cite><a href="#rfc3339">RFC 3339</a></cite>, which include the relevant part of ISO 8601 in ABNF form. The time scheme identifier is "clock".
</p><div class="exampleInner"><a id="clocktimedef" name="clocktimedef" /><pre>
datetime = <date-time, defined in <cite><a href="#rfc3339">RFC 3339</a></cite>>
clocktimedef = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
clockformat = %x63.6C.6F.63.6B ; "clock"
clocktime = (datetime / walltime / date)
; WARNING: if your date-time contains '+' (or any other reserved character, per <cite><a href="#rfc3986">RFC 3986</a></cite>),
; it should be percent-encoded when used in a URI.
</pre></div><p>For convenience, the definition is copied here</p><div class="exampleInner"><a id="datetime" name="datetime" /><pre>
; defined in <cite><a href="#rfc3339">RFC 3339</a></cite>
;
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
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
t=clock:2009-07-26T11:19:01Z,2009-07-26T11:20:01Z # => results in a 1 min interval
# on 26th Jul 2009 from 11hrs, 19min, 1sec
t=clock:2009-07-26T11:19:01Z # => starts on 26th Jul 2009 from 11hrs, 19min, 1sec
t=clock:,2009-07-26T11:20:01Z # => ends on 26th Jul 2009 from 11hrs, 20min, 1sec</pre></div></div></div><div class="div3">
<h4><a id="naming-space" name="naming-space" />4.3.2 Spatial Dimension</h4><p>
Spatial clipping selects an area of pixels from visual media streams. For this release of the media fragment specification, only rectangular selections are supported. The rectangle can be specified as pixel coordinates or percentages.
</p><p>
Rectangle selection is denoted by the name <code>xywh</code>. The value is an optional format <code>pixel:</code> or <code>percent:</code> (defaulting to pixel) and 4 comma-separated integers. The integers denote x, y, width and height, respectively, with x=0, y=0 being the top left corner of the image. If percent is used, x and width are interpreted as a percentage of the width of the original media, and y and height are interpreted as a percentage of the original height.
</p><div class="exampleInner"><a id="spacesegment" name="spacesegment" /><pre>
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"
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
xywh=160,120,320,240 # => results in a 320x240 box at x=160 and y=120
xywh=pixel:160,120,320,240 # => results in a 320x240 box at x=160 and y=120
xywh=percent:25,25,50,50 # => results in a 50%x50% box at x=25% and y=25%</pre></div></div><div class="div3">
<h4><a id="naming-track" name="naming-track" />4.3.3 Track Dimension</h4><p>
Track selection allows the extraction of a single track (audio, video, subtitles, etc) from a media container that supports multiple tracks. Track selection is denoted by the name <code>track</code>. The value is a string. Percent-escaping can be used in the string to specify unsafe characters, see the grammar below for details. Interpretation of the string depends on the container format of the original media: some formats allow numbers only, some allow full names.
</p><div class="exampleInner"><a id="tracksegment" name="tracksegment" /><pre>
trackprefix = %x74.72.61.63.6B ; "track"
trackparams = trackparam *( ";" trackparam )
trackparam = utf8string
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
track=1 # => results in only extracting track 1
track=video;subtitle # => results in extracting track 'video' and track 'subtitle'
track=Wide%20Angle%20Video # => results in only extracting track 'Wide Angle Video'</pre></div><p>
As the allowed track names are determined by the original source media, this information has to be known before construction of the media fragment. There is no support for generic media type names (audio, video) across container formats: most container formats allow multiple tracks of each media type, which would lead to ambiguities.
</p><table border="1" summary="Editorial note: Jack"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Jack</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>The issue of generic track names is still under discussion, <a href="http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4">ISSUE-4</a> in the tracker has the details.
</p>
</td></tr></table></div><div class="div3">
<h4><a id="naming-name" name="naming-name" />4.3.4 Named Dimension</h4><p>
Name-based selection is denoted by the name <code>id</code>, with the value being a string enclosed in single quotes. Percent-escaping can be used in the string to include unsafe characters such as single quote, see the grammer below for details. Interpretation of the string depends on the underlying container format: some container formats support named chapters or numbered chapters (leading to temporal clipping), some may support naming of groups of tracks or other objects. As with track selection, determining which names are valid requires knowledge of the original media item.
</p><div class="exampleInner"><a id="namesegment" name="namesegment" /><pre>
nameprefix = %x69.64 ; "id"
nameparam = utf8string
</pre></div><p>Examples:</p><div class="exampleInner"><pre>
id=1 # => results in only extracting the section called '1'
id=chapter-1 # => results in only extracting the section called 'chapter-1'
id=Airline%20Edit # => results in only extracting the section called 'Airline Edit'</pre></div><p>
Note that, despite the use of the name <code>id</code>, there is no correspondence to XML <code>id</code>: the values are uninterpreted strings, from the point of view of media fragment handling.
</p></div><div class="div3">
<h4><a id="common-syntax" name="common-syntax" />4.3.5 Common Syntax</h4><div class="exampleInner"><pre>
DIGIT = <DIGIT, defined in <cite><a href="#rfc4234">RFC 4234</a></cite>>
pchar = <pchar, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>>
unreserved = <unreserved, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>>
pct-encoded = <pct-encoded, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>>
fragment = <pct-encoded, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>>
utf8string = *( unreserved / pct-encoded ":" / "@" ) ; utf-8 character
; encoded using <cite><a href="#">rfc3896</a></cite> rules.
</pre></div><p>For convenience, the definitions are copied here. Only the definitions in the original documents are considered normative</p><div class="exampleInner"><a id="importeddefs" name="importeddefs" /><pre>
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment = *( pchar / "/" / "?" )
</pre></div></div></div></div><div class="div1">
<h2><a id="media-fragment-processing" name="media-fragment-processing" />5 Media Fragments Processing</h2><p>There are many open questions about how to resolve a media fragment URI that are not being answered simply from the specification of the syntax. An implementer will need to know all of these. This starts with issues around standardisation and uptake, followed by issues of interpretation of the syntax, followed by concrete protocol exchange scenarios for the different situations explained above in section <a href="#fragment-query"><b>3 URI fragment and URI query</b></a>.
</p><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">NOTE to implementers: if you come across some (not yet mentioned) issues here, please email to public-media-fragment@w3.org.</td></tr></table><div class="div2">
<h3><a id="processing-overview" name="processing-overview" />5.1 Overview</h3><table border="1" summary="Editorial note: Raphael"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Raphael</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">Rephrase this section. Some bits might end up in other sections.</td></tr></table><p>This is a list of hints to implementers on how to interpret media fragment URIs. There is no particular order to them.</p><p>
<em>Media type:</em> The media type of a resource retrieved through a URI fragment request is the same as that of the primary resource. Thus, retrieval of e.g. a single frame from a video will result in a one-frame-long video. Or, retrieval of all the audio tracks from a video resource will result in a video and not a audio resource. When using a URI query approach, media type changes are possible. E.g. a spatial fragment from a video at a certain time offset could be retrieved as a jpeg using a specific HTTP "Accept" header in the request.
</p><p>
<em>Synchronisation:</em> Synchronisation between different tracks of a media resource needs to be maintained when retrieving media fragments of that resource. This is true for both, URI fragment and URI query retrieval. With URI queries, when transcoding is required, a non-perceivable change in the synchronisation is acceptable.
</p><p>
<em>Embedded Timecodes:</em> When a media resource contains embedded time codes, these need to be maintained for media fragment retrieval, in particular when the URI fragment method is used. When URI queries are used and transcoding takes place, the embedded time codes should remain when they are useful and required.
</p><p>
<em>Resolution Order:</em> Where multiple dimensions are combined in one URI fragment request, implementations are expected to first do track and temporal selection on the container level, and then do spatial clipping on the codec level. Named selection is done for whatever the name stands for: a track, a temporal section, or a spatial region.
</p><p>
<em>Reasonable Byte Clipping:</em> A media fragment that is retrieved using URI fragment requests needs to be implementable without transcoding solely based on byte ranges. Temporal or spatial clipping needs to be as close as reasonably possible to what the media fragment specified. "Reasonably close" means the nearest compression entity to the requested fragment that completely contains the requested fragment. This means, e.g. for temporal fragments if a request is made for <code>http://www.example.org/video.ogv#t=60,100</code>, but the closest decodable range is <code>t=58,102</code> because this is where a packet boundary lies for audio and video, then it will be this range that is returned. Similarly for spatial ranges. The UA is then capable of displaying only the requested subpart, and should also just do that. For some container formats this is a non-issue, because the container format allows specification of logical begin and end.
</p><p>
<em>External Clipping:</em> There is no obligatory resolution method for a situation where a media fragment URI is being used in the context of another clipping method. Formally, it is up to the context embedding the media fragment URI to decide whether the outside clipping method overrides the media fragment URI or cascades, i.e. is defined on the resulting resource. In the absence of strong reasons to do otherwise we suggest cascading. An example is a SMIL element as follows: <code><smil:video clipBegin="5" clipEnd="15" src="http://www.example.com/example.mp4#t=100,200"/></code>. This should start playback of the original media resource at second 105, and stop at 115.
</p></div><div class="div2">
<h3><a id="processing-protocol-frag" name="processing-protocol-frag" />5.2 Protocol for URI fragment Resolution in HTTP</h3><p>This section defines what protocol steps are necessary in HTTP <cite><a href="#rfc2616">RFC 2616</a></cite> to resolve and deliver a media fragment specified as a URI fragment.</p><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>We could do RTSP as well, as mentioned earlier.</p>
</td></tr></table><div class="div3">
<h4><a id="processing-protocol-UA-mapped" name="processing-protocol-UA-mapped" />5.2.1 UA mapped byte ranges</h4><table border="1" summary="Editorial note"><tr><td width="50%" valign="top" align="left"><b>Editorial note</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>This section is ready to implement.</p>
</td></tr></table><p>As described in section <a href="#URIfragment-user-agent"><b>3.2 Resolving URI fragments within the user agent</b></a>, the most optimal case is a user agent that knows how to map media fragments to byte ranges. This is the case typically where a user agent has already downloaded those parts of a media resource that allow it to do or guess the mapping, e.g. headers or a resource, or an index of a resource.
</p><p>In this case, the HTTP exchanges are exactly the same as for any other Web resource where byte ranges are requested <cite><a href="#rfc2616">RFC 2616</a></cite>.
</p><p>How the UA retrieves the byte ranges is dependent on the media type of the media resource.
We here show examples with only one byte range retrieval per time range, which may
in practice turn into several such retrieval actions necessary to acquire the correct
time range.
</p><p>Here are the three principle cases a media fragment enabled UA and a media Server will encounter:</p><div class="div4">
<h5><a id="processing-protocol-UA-mapped-new" name="processing-protocol-UA-mapped-new" />5.2.1.1 UA requests URI fragment for the first time</h5><p>A user requests a media fragment URI:</p><ul><li><p>User → UA (1):</p><div class="exampleInner"><pre>http://www.example.com/video.ogv#t=10,20</pre></div></li></ul><p>The UA has to check if a local copy of the requested fragment is available in its buffer - not in this case. But it knows how to map the fragment to byte ranges: 19147 - 22890. So, it requests these byte ranges from the server:</p><ul><li><p>UA (1) → Proxy (2) → Origin Server (3):</p><div class="exampleInner"><pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: bytes=19147-22890</pre></div></li></ul><p>The server extracts the bytes corresponding to the requested range and replies in a 206 HTTP response:</p><ul><li><p>Origin Server (3) → Proxy (4) → UA (5):</p><div class="exampleInner"><pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Etag: "b7a60-21f7111-46f3219476580"
{binary data}</pre></div></li></ul><p>Assuming the UA has received the byte ranges that it requires to serve t=10,20, which may well be slightly more, it will serve the decoded content to the User from the appropriate time offset. Otherwise it may keep requesting byte ranges to retrieve the required time segments.</p><img src="MF-SD-ClientSide-5.2.1.1.png" alt="Illustration of a UA requesting a URI fragment for the first time" /></div><div class="div4">
<h5><a id="processing-protocol-UA-mapped-unchanged" name="processing-protocol-UA-mapped-unchanged" />5.2.1.2 UA requests URI fragment it already has buffered</h5><p>A user requests a media fragment URI:</p><ul><li><p>User → UA (1):</p><div class="exampleInner"><pre>http://www.example.com/video.ogv#t=10,20</pre></div></li></ul><p>The UA has to check if a local copy of the requested fragment is available in its buffer - it is in this case. But the resource could have changed on the server, so it needs to send a conditional GET. It knows the byte ranges: 19147 - 22890. So, it requests these byte ranges from the server under condition of it having changed:</p><ul><li><p>UA (1) → Proxy (2) → Origin Server (3):</p><div class="exampleInner"><pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
If-Modified-Since: Sat, 01 Aug 2009 09:34:22 GMT
If-None-Match: "b7a60-21f7111-46f3219476580"
Range: bytes=19147-22890</pre></div></li></ul><p>The server checks if the resource has changed by checking the date - in this case, the resource was not modified. So, the server replies with a 304 HTTP response. (Note that a If-Range header cannot be used, because if the entity has changed, the entire resource would be sent.)</p><ul><li><p>Origin Server (3) → Proxy (4) → UA (5):</p><div class="exampleInner"><pre>HTTP/1.1 304 Not Modified
Accept-Ranges: bytes
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Etag: "b7a60-21f7111-46f3219476580"</pre></div></li></ul><p>So, the UA serves the decoded resource to the User our of its existing buffer.</p><img src="MF-SD-ClientSide-5.2.1.2.png" alt="Illustration of a UA requesting a URI fragment it already has buffered" /></div><div class="div4">
<h5><a id="processing-protocol-UA-mapped-changed" name="processing-protocol-UA-mapped-changed" />5.2.1.3 UA requests URI fragment of a changed resource</h5><p>A user requests a media fragment URI and the UA sends the exact same GET request as described in the previous subsection.</p><p>This time, the server checks if the resource has changed by checking the date and it has been modified. Since the byte mapping may not be correct any longer, the server can only tell the UA that the resource has changed and leave all further actions to the UA. So, it sends a 412 HTTP response:</p><ul><li><p>Origin Server (3) → Proxy (4) → UA (5):</p><div class="exampleInner"><pre>HTTP/1.1 412 Precondition Failed
Accept-Ranges: bytes
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/22222222
Etag: "xxxxx-yyyyyyy-zzzzzzzzzzzzz"</pre></div></li></ul><p>So, the UA can only assume the resource has changed and re-retrieve what it needs to get back to being able to retrieve fragments. For most resources this may mean retrieving the header of the file. After this it is possible again to do a byte range retrieval.</p><img src="MF-SD-ClientSide-5.2.1.3.png" alt="Illustration of a UA requesting a URI fragment it has buffered, but that changed" /></div></div><div class="div3">
<h4><a id="processing-protocol-Server-mapped" name="processing-protocol-Server-mapped" />5.2.2 Server mapped byte ranges</h4><p>As described in section <a href="#URIfragment-server"><b>3.3 Resolving URI fragments with server help</b></a>, some User Agents cannot undertake the framgent-to-byte mapping themselves, because the mapping is not obvious. This typically applies to media formats where the setup of the decoding pipeline does not imply knowledge of how to map fragments to byte ranges, e.g. Ogg without OggIndex. Thus, the User Agent would be capable of decoding a continuous resource, but would not know which bytes to request for a media fragment.
</p><p>In this case, the User Agent could either guess at what byte ranges it has to retrieve and the retrieval action would follow the previous case. Or it could hope that the server provides a special service, which would allow it to retrieve the byte ranges with a simple request of the media fragment ranges. Thus, the HTTP request of the User Agent will include a request for the fragment hoping that the server can do the byte range mapping and send back the appropriate byte ranges.</p><p>We'll go through the protocol exchange action step by step. It starts with a user's request for a media fragment URI:</p><ul><li><p>User → UA (1):</p><div class="exampleInner"><pre>http://www.example.com/video.ogv#t=10,20</pre></div></li></ul><p>The UA has to check if a local copy of the requested fragment is available in its buffer. If it is, we revert back to the processing described in sections <a href="#processing-protocol-UA-mapped-unchanged"><b>5.2.1.2 UA requests URI fragment it already has buffered</b></a> and <a href="#processing-protocol-UA-mapped-changed"><b>5.2.1.3 UA requests URI fragment of a changed resource</b></a>, since the UA already knows the mapping to byte ranges.</p><p>When the UA doesn't know how to map time to bytes, it tries requesting this time range from the server:</p><ul><li><p>UA (1) → Proxy (2) → Origin Server (3):</p><div class="exampleInner"><pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: t:npt=10-20</pre></div></li></ul><p>The example shows a temporal Range request, which introduces the "t" dimension and the "npt" unit. The specification for all new Range dimensions is given through:</p><ul><li><p><em>temporal:</em> t:<unit>=<start> - <end></p></li><li><p><em>spatial:</em> xywh:<unit>=<topleftx>,<toplefty>,<width>,<height></p></li><li><p><em>track:</em> track=<trackname> [; <trackname>]*</p></li><li><p><em>name:</em> id=<name></p></li></ul><p>The unit is not optional. It can be "npt", "smpte", "smpte-25", "smpte-30", "smpte-30-drop" or "clock" for temporal and "pixel" or "percent" for spatial. Where "ntp" is used for a temporal Range, only specification in seconds is possible without the "s". Where "clocktime" is used for a temporal Range, only "datetime" is possible and "walltime" is fully specified in HHMMSS with fraction and full timezone. Indeed, all optional elements in the URI specification become required in the Range header.</p><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>Somebody should create an ABNF for these new Range dimensions.
</p>
</td></tr></table><p>If the server doesn't understand a Range header, it MUST ignore the header field that includes that range-set. This is in sync to the HTTP RFC <cite><a href="#rfc2616">RFC 2616</a></cite>. This means that where a server doesn't support media fragments, the complete resource will be delivered. It also means that we can combine both, byte range and fragment range headers in one request, since the server will only react to the Range header it understands.</p><p>Assuming the server can map the given Range to one or more byte ranges, it will reply with these in a 206 HTTP response. Where multiple byte ranges are required to satisfy the Range request, these are transmitted as a multipart message-body. The media type for this purpose is called "multipart/byteranges". This is in sync with the HTTP RFC <cite><a href="#rfc2616">RFC 2616</a></cite>.</p><p>Here is the reply to the example above, assuming a single byte range is sufficient:</p><ul><li><p>Origin Server (3) → Proxy (4) → UA (5):</p><div class="exampleInner"><pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, xywh, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Content-Range-Mapping: t:npt 11.85-21.16/653.791
Etag: "b7a60-21f7111-46f3219476580"
{binary data}</pre></div></li></ul><p>Note that there is a new header called Content-Range-Mapping, which provides the mapping of the retrieved byte range to the original Content-Range request, which was not in bytes. In comparison to the specification in the request Range header, the reply Content-Range-Mapping header also adds the instance-length after a slash "/" character in analogy to the Content-Range header. Also note that through the extended list in the Accept-Ranges it is possible to identify which fragment schemes a server supports.</p><ul><li><p><em>temporal:</em> t:<unit>=<start> - <end>/<duration></p></li><li><p><em>spatial:</em> xywh:<unit>=<topleftx>,<toplefty>,<width>,<height>/<total_width>,<total_height></p></li><li><p><em>track:</em> track=<trackname1>[; <trackname2>]*/<duration></p></li><li><p><em>name:</em> id=<name>/*</p></li></ul><p>For temporal it is the total duration in seconds, for spatial the total width and height dimension, for track again the total duration in seconds, for id just "*" since it could be any of the other dimensions.</p><p>Also note that, as we return both, byte and temporal ranges, the UA and any intermediate caching proxy is enabled to map byte positions with time offsets and fall back to byte range request where the fragment is re-requested.</p><img src="MF-SD-ServerSide.png" alt="Illustration of a UA requesting a URI time to byte range mapping from the server " /><p>In the case where a media fragment results in a multipart message-body, the bytes Content-Range headers will be spread throughout the binary data ranges, but the Content-Range-Mapping of the media fragment will only be with the main header. For example:</p><ul><li><p>Origin Server (3) → Proxy (4) → UA (5):</p><div class="exampleInner"><pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, xywh, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range-Mapping: track audio1,video1/653.791
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
Etag: "b7a60-21f7111-46f3219476580"
--THIS_STRING_SEPARATES
Content-type: video/ogg
Content-Range: bytes 123-2589/35614993
{binary data}
--THIS_STRING_SEPARATES
Content-type: video/ogg
Content-Range: bytes 14560-27891/35614993
{binary data}
--THIS_STRING_SEPARATES
Content-type: video/ogg
Content-Range: bytes 58909-81230/35614993
{binary data}
--THIS_STRING_SEPARATES--</pre></div></li></ul><p>Note that a caching proxy that does not understand a Range header must not cache "206 Partial Content" responses as per HTTP RFC <cite><a href="#rfc2616">RFC 2616</a></cite>. Thus, the new Range requests won't be cached by legacy Web proxies.</p><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>There is discussion in the group still whether "track" and "id" dimension can actually be handled in the same way as temporal and spatial, see <a href="http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments">Conrad's Fragment proposal</a>.</p>
<p>Need to specify the ABNF for the Content-Range-Mapping header.</p>
</td></tr></table></div><div class="div3">
<h4><a id="processing-protocol-proxy" name="processing-protocol-proxy" />5.2.3 Proxy cacheable Server mapped byte ranges</h4><p>As described in section <a href="#URIfragment-proxies"><b>3.4 Resolving URI fragments in a proxy cacheable manner</b></a>, the server mapped byte ranges approach can be extended to play with existing caching Web proxy infrastructure. This is important, since video is a huge bandwidth eater in the current Internet and falling back to using existing Web proxy infrastructure is important, particularly since progressive download and direct access mechanisms for video rely heavily on this functionality. Over time, the proxy infrastructure will learn how to cache media fragment URIs directly as described in the previous section and then will not require this extra effort.</p><p>To enable media-fragment-URI-supporting UAs to make their retrieval cachable, we introduce some extra HTTP headers, which will help tell the server and the proxy what to do.</p><p>Let's play it through on an example. A user requests a media fragment URI:
</p><ul><li><p>User → UA (1):</p><div class="exampleInner"><pre>http://www.example.com/video.ogv#t=10,20</pre></div></li></ul><p>The UA has to check if a local copy of the requested fragment is available in its buffer. In our case here, it is not. If it was, we would revert back to the processing described in sections <a href="#processing-protocol-UA-mapped-unchanged"><b>5.2.1.2 UA requests URI fragment it already has buffered</b></a> and <a href="#processing-protocol-UA-mapped-changed"><b>5.2.1.3 UA requests URI fragment of a changed resource</b></a>, since the UA already knows the mapping to byte ranges. The UA issues a HTTP GET request with the fragment and requesting to retrieve just the mapping to byte ranges:</p><ul><li><p>UA (1) → Proxy (2) → Origin Server (3):</p><div class="exampleInner"><pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: t:npt=10-20
Accept-Range-Redirect: bytes</pre></div></li></ul><p>The server converts the given time range to a byte range and sends an empty reply that refers the UA to the right byte range for the correct time range. The message body of this answer contains the control section of fragf2f.mp4#12,21 (if required).
</p><ul><li><p>Origin Server (3) → Proxy (4) → UA (5):</p><div class="exampleInner"><pre>HTTP/1.1 307 Temporary Redirect
Location: http://www.example.com/video.ogv
Accept-Ranges: bytes, t, xywh, track, id
Content-Length: 0
Content-Type: video/ogg
Content-Range-Mapping: t:npt 11.85-21.16/653.791
Range-Redirect: 19147-22880
Vary: Accept-Range-Redirect</pre></div></li></ul><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>I have removed X-Accept-Range-Redirect - the X-Range-Redirect header already indicates that a mapping to byte ranges has been undertaken and the Accept-Ranges header shows which fragment addressing types the server can resolve. Need to discuss.</p>
<p>I have also removed the delivery of header information - for a URI fragment resolution, that's not necessary. When applying this to a URI query, however, it will be necessary, since the URI query delivers a completely new resource.</p>
<p>I further added the Content-Range-Mapping header, because it will tell the client what actual fragment data is being delivered, so this is required for the UA to get the actual mapping between fragment and byte ranges.</p>
<p>I am using "307 Temporary Redirect" and thus Range-Redirect (rather than Range-Refer) to return the reply without data in the reply.</p>
<p>We need an ABNF specification for Range-Redirect, which could contain a large number of ranges, then to be separated by comma.</p>
</td></tr></table><p>The UA proceeds to put the actual fragment request through as a normal byte range request as in section <a href="#processing-protocol-UA-mapped-new"><b>5.2.1.1 UA requests URI fragment for the first time</b></a>:</p><ul><li><p>UA (5) → Proxy (6) → Origin Server (7):</p><div class="exampleInner"><pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: 19147-22880</pre></div></li></ul><p>The Origin Server puts the data together and sends it to the UA:</p><ul><li><p>Origin Server (7) → Proxy (8) → UA (9):</p><div class="exampleInner"><pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, xywh, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Content-Range-Mapping: t:npt 11.85-21.16/653.791
Etag: "b7a60-21f7111-46f3219476580"
{binary data}</pre></div></li></ul><p>The UA decodes the data and displays it from the requested offset. The caching Web proxy in the middle has now cached the byte range, since it adhered to the normal byte range request protocol. All existing caching proxies will work with this. New caching Web proxies may learn to interpret media fragments natively, so won't require the extra packet exchange described in this section.</p><img src="MF-SD-ProxyCacheable.png" alt="Illustration of a UA requesting a URI time to byte range mapping from the server with proxy capability of byte ranges" /></div></div><div class="div2">
<h3><a id="processing-protocol-query" name="processing-protocol-query" />5.3 Protocol for URI query Resolution in HTTP</h3><p>This section describes the protocol steps used in HTTP <cite><a href="#rfc2616">RFC 2616</a></cite> to resolve and deliver a media fragment specified as a URI query.</p><p>A user requests a media fragment URI using a URI query:</p><ul><li><p>User → UA (1):</p><div class="exampleInner"><pre>http://www.example.com/video.ogv?t=10,20</pre></div></li></ul><p>This is a full resource, so it is a simple HTTP retrieval process. The UA has to check if a local copy of the requested resource is available in its buffer. If yes, it does a conditional GET with e.g. an If-Modified-Since and If-None-Match HTTP header.</p><p>Assuming the resource has not been retrieved before, the following is sent to the server:</p><ul><li><p>UA (1) → Proxy (2) → Origin Server (3):</p><div class="exampleInner"><pre>GET /video.ogv?t=10,20 HTTP/1.1
Host: www.example.com
Accept: video/*</pre></div></li></ul><p>If the server doesn't understand these query parameters, it typically ignores them and returns the complete resource. This is not a requirement by the URI or the HTTP standard, but the way it is typically implemented in Web browsers.</p><p>A media fragment supporting server has to create a complete media resource for the URI query, which in the case of Ogg requires creation of a new resource by adapting the existing Ogg file headers and combining them with the extracted byte range that relates to the given fragment. Some of the codec data may also need to be re-encoded since, e.g. t=10 does not fall clearly on a decoding boundary, but the retrieved resource must match as closely as possible the URI query. This new resource is sent back as a reply:</p><ul><li><p>Origin Server (3) → Proxy (4) → UA (5):</p><div class="exampleInner"><pre>HTTP/1.1 200 OK
Content-Length: 3782
Content-Type: video/ogg
Etag: "b7a60-21f7111-46f3219476580"
{binary data}</pre></div></li></ul><p>The UA serves the decoded resource to the User. Caching in Web proxies works as it has always worked - most modern Web servers and UAs implement a caching strategy for URIs that contain a query using one of the three methods for marking freshness: heuristic freshness analysis, the Cache-Control header, or the Expires header. In this case, many copies of different segments of the original resource video.ogv may end up in proxy caches. An intelligent media proxy in future may devise a strategy to buffer such resources in a more efficient manner, where headers and byte ranges are stored differently.</p><p>It is possible to add an additional HTTP response header called "Link" that refers the new resource back to the original resource and enables the UA to retrieve further information about the original resource, such as its full length. In this case, the user agent is also enable to choose to display the dimensions of the primary resource or the one created by the query.</p><p>Further, media fragment URI queries can be extended to enable UAs to use the Range-Redirect HTTP header to also revert back to a byte range request. This is analogous to section <a href="#processing-protocol-proxy"><b>5.2.3 Proxy cacheable Server mapped byte ranges</b></a>.</p><p>Not that a server that doesn't support media fragments through either URI fragment or query addressing, will return the full resource in either case. It is therefore not possible to first try URI fragment addressing, and when that fails to try URI query addressing.</p><table border="1" summary="Editorial note: Silvia"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Silvia</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>somebody should paint time-sequence diagrams for the protocol action.</p>
</td></tr></table></div></div><div class="div1">
<h2><a id="media-fragment-semantics" name="media-fragment-semantics" />6 Media Fragments Semantics</h2><p>Errors can occur at several levels:</p><ul><li>the complete URI (e.g. spatial dimension on a audio resource)</li><li>the combination of name-value strings (e.g. name and time dimension combined)</li><li>the name-value string (e.g. invalid percent-encoding)</li><li>the name dimension (e.g. undefined dimension)</li><li>the value (e.g. invalid NPT syntax)</li></ul><p>We will look at errors in the different dimensions and their values in the subsequent sub-sections and we will start with errors on the more general levels.
</p><div class="div2">
<h3><a id="error-general" name="error-general" />6.1 Errors on the General URI level</h3><div class="div3">
<h4><a id="error-general-non-existent" name="error-general-non-existent" />6.1.1 Non-existent dimension:</h4><p>Attempting to do fragment selection on a dimension that does not exist in the source media, such as temporal clipping on a still image or spatial clipping on an audio file, should be considered a no-op and not throw an error.
</p></div><div class="div3">
<h4><a id="error-general-underspec" name="error-general-underspec" />6.1.2 Under-specified Dimension</h4><p>The result of doing spatial clipping on a media resource that has multiple video tracks is that the spatial clipping is applied to all tracks.
</p></div></div><div class="div2">
<h3><a id="error-temporal" name="error-temporal" />6.2 Errors on the temporal dimensions</h3><p>Assuming a single temporal dimension is present, we now analyse what content can appear here and how it should be handled.
</p><div class="div3">
<h4><a id="error-temporal-valid" name="error-temporal-valid" />6.2.1 Validity error</h4><p>The value cannot be parsed for the dimension.</p><p>Examples:</p><ul><li>t=asdf</li><li>t=5,ekj</li><li>t=agk,9</li></ul><p>Result: 200 OK</p><p>Effect: ignore the fragment and retrieve the full resource (with this given URL)</p><p>Note: browsers already support this</p></div><div class="div3">
<h4><a id="error-temporal-non-existent" name="error-temporal-non-existent" />6.2.2 Non-existent</h4><p>The value resolves to nothing, i.e. t=a,b with a>b.</p><p>Examples:</p><ul><li>t=20,10</li></ul><p>Result: 200 OK</p><p>Effect: ignore the fragment and retrieve the full resource (with this given URL)</p><p>Note: browsers already support this</p></div><div class="div3">
<h4><a id="error-temporal-undefined" name="error-temporal-undefined" />6.2.3 Undefined</h4><p>The time segments are undefined.</p><p>Examples:</p><ul><li>t=,</li></ul><p>Result: 200 OK</p><p>Effect: ignore the fragment and retrieve the full resource (with this given URL)</p><p>Note: browsers already support this</p></div><div class="div3">
<h4><a id="error-temporal-empty" name="error-temporal-empty" />6.2.4 Empty</h4><p>The resolved time segment is empty.</p><p>Examples:</p><ul><li>t=0,0</li><li>t=3,3</li></ul><p>Result: 200 OK</p><p>Effect: retrieve whatever the browser needs to set up playback and set the playback position to the offset</p></div><div class="div3">
<h4><a id="error-temporal-offset" name="error-temporal-offset" />6.2.5 Offset</h4><p>The value only contains a time value - a legacy deep link.</p><p>Examples:</p><ul><li>t=0</li><li>t=14</li></ul><p>Result: 200 OK</p><p>Effect: return representation of the media resource from second 14 on in seconds</p></div><div class="div3">
<h4><a id="error-temporal-non-error" name="error-temporal-non-error" />6.2.6 Non-errors</h4><p>For t=a,b with b>=a</p><ul><li>t=a,b results in 200 OK: play back from a to b (the normal case)</li><li>t=a, results in 200 OK: play back from a to the end of the resource</li><li>t=,b results in 200 OK: play back from start of resource to b</li><li>t=a,b with a=b results in 200 OK: set playback position to a</li><li>t=a,b with a<start results in 200 OK: play back from start of resource to b</li><li>t=a,b with a>end results in 200 OK: set playback position to resource end</li><li>t=a,b with b>end results in 200 OK: play back from a to resource end</li><li>t=a,b with b<start results in 200 OK: set playback position to start</li></ul></div></div><div class="div2">
<h3><a id="error-spatial" name="error-spatial" />6.3 Errors on the spatial dimensions</h3><p>Assuming a single spatial dimension is present, we now analyse what content can appear here and how it should be handled.
</p></div><div class="div2">
<h3><a id="error-track" name="error-track" />6.4 Errors on the track dimensions</h3><p>Assuming a single track dimension is present, we now analyse what content can appear here and how it should be handled.
</p></div><div class="div2">
<h3><a id="error-named" name="error-named" />6.5 Errors on the named dimensions</h3><p>Assuming a single named dimension is present, we now analyse what content can appear here and how it should be handled.
</p></div><table border="1" summary="Editorial note: Michael"><tr><td width="50%" valign="top" align="left"><b>Editorial note: Michael</b></td><td width="50%" valign="top" align="right"> </td></tr><tr><td valign="top" align="left" colspan="2">
<p>We need to define more error semantics. Some areas:</p>
<ol class="enumar"><li><p>Nonexistent (t= with begin and end past end-of-media, unknown id, unknown track)</p></li><li><p>Partially existent (t= with end past EOM, xywh spec that extends past bounds): could be clipped to the actual size of the resource</p></li><li><p>Non-existent that can be determined statically, for example t=20,10</p></li><li><p>Incompatible: if the named dimension is used, all the other dimensions are ignored. Alternatively: this is an error.</p></li></ol>
</td></tr></table></div><div class="div1">
<h2><a id="media-fragment-display" name="media-fragment-display" />7 Displaying Media Fragments</h2><p>
When dealing with media fragments, there is a question whether to display the media fragment in context or without context.
In general, it is recommended to display a URI fragment in context since it is part of a larger resource.
On the other hand, a URI query results in a new resource, so it is recommended to display it as a complete resource without context.
The next paragraphs discuss for each axis the context of a media fragment and provides suggestions regarding the visualization of the URI fragment within its context.
</p><p>
For a temporal URI fragment, it is recommended to start playback at a time offset that equals to the start of the fragment and pause at the end of the fragment. When the "play" button is hit again,
the resource will continue loading and play back beyond the end of the fragment. When seeking to specific offsets, the resource will load and play back from those seek points. It is also recommended
to introduce a "reload" button to replay just the URI fragment. In this way, a URI fragment basically stands for "focusing attention". Additionally, temporal URI fragments could be highlighted on the
transport bar.
</p><p>
For a spatial URI fragment, it is recommended to emphasize the spatial region during playback. For instance, the spatial region could be indicated by means of a bounding box or the background
(i.e., all the pixels that are not contained within the region) could be blurred or darkened.
</p><p>
Finally, for track URI fragments, it is recommended to play only the tracks identified by the track URI fragment. If no tracks are specified, the default tracks should be played.
Different tracks could be selected using dropdown boxes or buttons; the selected tracks are then highlighted during playback. The way the UA retrieves information regarding the available tracks of
a particular resource is out of scope for this specification.
</p></div><div class="div1">
<h2><a id="conclusions" name="conclusions" />8 Conclusions</h2><div class="div2">
<h3><a id="qualification-resources" name="qualification-resources" />8.1 Qualification of Media Resources</h3><p>
HTTP byte ranges can only be used to request media fragments if these media fragments can be expressed in terms of byte ranges. This restriction implies that media resources should fulfil the following conditions:
</p><ul><li><p>The media fragments can be extracted in the compressed domain;</p></li><li><p>No syntax element modifications in the bitstream are needed to perform the extraction.</p></li></ul><p>
Not all media formats will be compliant with these two conditions. Hence, we distinguish the following categories:
</p><ol class="enumar"><li><p>The media resource meets the two conditions (i.e., fragments can be extracted in the compressed domain and no syntax element modifications are necessary). In this case, caching media fragments of such media resources is possible using HTTP byte ranges, because their media fragments are addressable in terms of byte ranges.
</p></li><li><p>
Media fragments can be extracted in the compressed domain, but syntax element modifications are required. These media fragments are cacheable using HTTP byte ranges on condition that the syntax element modifications are needed in media-headers applying to the whole media resource/fragment. In this case, those media-headers could be sent to the client in the first response of the server, which is a response to a request on a specific resource different from the byte-range content.
</p></li><li><p>
Media fragments cannot be extracted in the compressed domain. In this case, transcoding operations are necessary to extract media fragments. Since these media fragments are not expressible in terms of byte ranges, it is not possible to cache these media fragments using HTTP byte ranges. Note that media formats which enable extracting fragments in the compressed domain, but are not compliant with category 2 (i.e., syntax element modifications are not only applicable to the whole media resource), also belong to this category.
</p></li></ol></div></div></div><div class="back"><div class="div1">
<h2><a id="references-normative" name="references-normative" />A References</h2><dl><dt class="label"><a name="rfc2119" />[RFC 2119] </dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key Words for use in RFCs to Indicate Requirement Levels</cite></a>. IETF RFC 2119, March 1997. Available at <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>.
</dd><dt class="label"><a name="rtsp" />[RFC 2326] </dt><dd>
<cite>Real Time Streaming Protocol (RTSP)</cite>. IETF RFC 2326, April 1998. Available at <a href="http://www.ietf.org/rfc/rfc2326.txt">http://www.ietf.org/rfc/rfc2326.txt</a>.
</dd><dt class="label"><a name="rfc2616" />[RFC 2616] </dt><dd>
<cite>Hypertext Transfer Protocol -- HTTP/1.1</cite>. IETF RFC 2616, June 1999. Available at <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>.
</dd><dt class="label"><a name="rfc3339" />[RFC 3339] </dt><dd>G. Klyne and C. Newman.
<cite>Date and Time on the Internet: Timestamps</cite>. IETF RFC 3339, July 2002. Available at <a href="http://www.ietf.org/rfc/rfc3339.txt">http://www.ietf.org/rfc/rfc3339.txt</a>.
</dd><dt class="label"><a name="ogg" />[RFC 3533] </dt><dd>
<cite>The Ogg Encapsulation Format Version 0</cite>. IETF RFC 3533, May 2003. Available at <a href="http://www.ietf.org/rfc/rfc3533.txt">http://www.ietf.org/rfc/rfc3533.txt</a>.
</dd><dt class="label"><a name="rfc3986" />[RFC 3986] </dt><dd>T. Berners-Lee and R. Fielding and L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite> Uniform Resource Identifier (URI): Generic Syntax</cite></a>. IETF RFC 3986, January 2005. Available at <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>.
</dd><dt class="label"><a name="rfc4234" />[RFC 4234] </dt><dd>D. Crocker, Ed. <a href="http://www.ietf.org/rfc/rfc4234.txt"><cite>Augmented BNF for Syntax Specifications: ABNF</cite></a>. IETF RFC 4234, October 2005. Available at <a href="http://www.ietf.org/rfc/rfc4234.txt">http://www.ietf.org/rfc/rfc4234.txt</a>.
</dd><dt class="label"><a name="rfc4288" />[RFC 4288] </dt><dd>N. Freed and J. Klensin <a href="http://www.ietf.org/rfc/rfc4288.txt"><cite>Media Type Specifications and Registration Procedures</cite></a>. IETF RFC 4288, December 2005. Available at <a href="http://www.ietf.org/rfc/rfc4288.txt">http://www.ietf.org/rfc/rfc4288.txt</a>.
</dd><dt class="label"><a name="rfc5147" />[RFC 5147] </dt><dd>
E. Wilde and M. Duerst.<a href="http://tools.ietf.org/html/rfc5147"><cite>URI Fragment Identifiers for the text/plain Media Type</cite></a>. IETF RFC 5147, April 2008. Available at <a href="http://tools.ietf.org/html/rfc5147">http://tools.ietf.org/html/rfc5147</a>.
</dd><dt class="label"><a name="html40" />[HTML 4.0] </dt><dd>D. Ragett and A. Le Hors and I. Jacobs.<a href="http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri"><cite>HTML Fragment identifiers</cite></a>. W3C Rec, December 1999. Available at <a href="http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri">http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri</a>.
</dd><dt class="label"><a name="html5" />[HTML 5] </dt><dd>Ian Hickson, Google (ed).<a href="http://www.w3.org/TR/2009/WD-html5-20090825/"><cite>HTML5</cite></a>. W3C Working Draft, 25th August 2009. Available at <a href="http://www.w3.org/TR/2009/WD-html5-20090825/">http://www.w3.org/TR/2009/WD-html5-20090825/</a>.
</dd><dt class="label"><a name="svg" />[SVG] </dt><dd>J. Ferraiolo.<a href="http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG"><cite>SVG Fragment identifiers</cite></a>. W3C Rec, September 2001. Available at <a href="http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG">http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG</a>.
</dd><dt class="label"><a name="smil30" />[SMIL] </dt><dd>Sjoerd Mullender, CWI (ed).<a href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/"><cite>Synchronized Multimedia Integration Language (SMIL 3.0)</cite></a>. W3C Recommendation 01 December 2008. Available at <a href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/">http://www.w3.org/TR/2008/REC-SMIL3-20081201/</a>.
</dd><dt class="label"><a name="xpointer" />[xpointer] </dt><dd>P. Grosso and E. Maler and J. Marsh and N. Walsh.<a href="http://www.w3.org/TR/xptr-framework/"><cite>XPointer Framework</cite></a>. W3C Rec, March 2003. Available at <a href="http://www.w3.org/TR/xptr-framework/">http://www.w3.org/TR/xptr-framework/</a>.
</dd><dt class="label"><a name="mpeg-7" />[MPEG-7] </dt><dd>
<cite>Information Technology - Multimedia Content Description Interface (MPEG-7)</cite>. Standard No. ISO/IEC 15938:2001, International Organization for Standardization(ISO), 2001.
</dd><dt class="label"><a name="temporalURI" />[temporal URI] </dt><dd>
S. Pfeiffer and C. Parker and A. Pang.<a href="http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html"><cite>Specifying time intervals in URI queries and fragments of time-based Web resources</cite></a>. Internet Draft, March 2005. Available at <a href="http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html">http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html</a>.
</dd><dt class="label"><a name="cmml" />[CMML] </dt><dd>
<cite>Continuous Media Markup Language (CMML), Version 2.1</cite>. IETF Internet-Draft 4th March 2006 <a href="http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt">http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt</a>.
</dd><dt class="label"><a name="roe" />[ROE] </dt><dd>
<cite>Rich Open multitrack media Exposition (ROE)</cite>. Xiph Wiki. Retrieved 13 April 2009 at <a href="http://wiki.xiph.org/index.php/ROE">http://wiki.xiph.org/index.php/ROE</a>.
</dd><dt class="label"><a name="skeleton" />[Skeleton] </dt><dd>
<cite>Ogg Skeleton</cite>. Xiph Wiki. Retrieved 13 April 2009 at <a href="http://wiki.xiph.org/OggSkeleton">http://wiki.xiph.org/OggSkeleton</a>.
</dd><dt class="label"><a name="mpeg21" />[MPEG-21] </dt><dd>
<cite>Information Technology - Multimedia Framework (MPEG-21)</cite>. Standard No. ISO/IEC 21000:2002, International Organization for Standardization(ISO), 2002. Available at <a href="http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip">http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip</a>.
</dd><dt class="label"><a name="smpte" />[SMPTE] </dt><dd>
<cite>SMPTE RP 136 Time and Control Codes for 24, 25 or 30 Frame-Per-Second Motion-Picture Systems</cite>
</dd><dt class="label"><a name="abnf" />[ABNF] </dt><dd>
<cite>Augmented BNF for Syntax Specifications: ABNF</cite>, Internet STD 68 (as of April 2009: <a href="http://tools.ietf.org/html/rfc5234">RFC 5234</a>).
</dd><dt class="label"><a name="isoBaseMediaFF" />[ISO Base Media File Format] </dt><dd>
<cite>Information technology - Coding of audio-visual objects - Part 12: ISO base media file format</cite>. Retrieved 13 April 2009 at <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip</a>
</dd><dt class="label"><a name="mf-req" />[Use cases and requirements for Media Fragments] </dt><dd>
<cite>Use cases and requirements for Media Fragments</cite>. W3C Working Draft 30 April 2009: <a href="http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/">http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/</a>
</dd><dt class="label"><a name="ecma-262" />[ECMA-262 5th edition] </dt><dd>
<cite>ECMA-262 5th edition</cite>: <a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">http://www.ecma-international.org/publications/standards/Ecma-262.htm</a>
</dd></dl></div><div class="div1">
<h2><a id="collected-syntax" name="collected-syntax" />B Collected ABNF Syntax (Non-Normative)</h2><div class="exampleInner"><pre>
; defined in <cite><a href="#rfc4234">RFC 4234</a></cite>
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; defined in <cite><a href="#rfc3986">RFC 3986</a></cite>
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
; defined in <cite><a href="#rtsp">RFC 2326</a></cite>
npt-sec = 1*DIGIT [ "." *DIGIT ] ; definitions taken
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from <cite><a href="#rtsp">RFC 2326</a></cite>
npt-hh = 1*DIGIT ; any positive number
npt-mm = 2DIGIT ; 0-59
npt-ss = 2DIGIT ; 0-59
; defined in <cite><a href="#rfc3339">RFC 3339</a></cite>
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
; <cite><a href="#rfc3986">RFC 3986</a></cite>
utf8string = *( unreserved / pct-encoded / ":" / "@" ) ; utf-8 character
; encoded using <cite><a href="#">rfc3896</a></cite> rules.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
mediasegment = namesegment / axissegment
axissegment = ( <a href="#timesegment">timesegment</a> / <a href="#spacesegment">spacesegment</a> / <a href="#tracksegment">tracksegment</a> )
*( "&" ( <a href="#timesegment">timesegment</a> / <a href="#spacesegment">spacesegment</a> / <a href="#tracksegment">tracksegment</a> )
;
; note that this does not capture the restriction to one kind of fragment
; in the axisfragment definition, unless we list explicitely the 14 cases.
;
timesegment = timeprefix "=" timeparam
timeprefix = %x74 ; "t"
timeparam = <a href="#npttimedef">npttimedef</a> / <a href="#smptetimedef">smptetimedef</a> / <a href="#clocktimedef">clocktimedef</a>
npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( "," npttime )
deftimeformat = %x6E.70.74 ; "npt"
npttime = npt-sec / npt-hhmmss
smptetimedef = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
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"
frametime = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]
clocktimedef = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
clockformat = %x63.6C.6F.63.6B ; "clock"
clocktime = (datetime / walltime / date)
datetime = date-time ; inclusion of <cite><a href="#rfc3339">RFC 3339</a></cite>
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 = utf8string
namesegment = nameprefix "=" nameparam
nameprefix = %x69.64 ; "id"
nameparam = utf8string
</pre></div></div><div class="div1">
<h2><a id="acknowledgments" name="acknowledgments" />C Acknowledgements (Non-Normative)</h2><p>
This document is the work of the <a href="http://www.w3.org/2008/WebVideo/Fragments/">W3C Media Fragments Working Group</a>. Members of the Working Group are
(at the time of writing, and in alphabetical order):
Eric Carlson (Apple, Inc.),
Michael Hausenblas (DERI Galway at the National University of Ireland, Galway, Ireland),
Philip Jägenstedt (Opera Software),
Jack Jansen (CWI),
Yves Lafon (W3C),
Wonsuk Lee (Electronics and Telecommunications Research Institute),
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),
David Singer (Apple, Inc.),
Raphaël Troncy (EURECOM),
Davy Van Deursen (IBBT),
</p><p>
The people who have contributed to <a href="http://lists.w3.org/Archives/Public/public-media-fragment/">
discussions on public-media-fragment@w3.org
</a> are also gratefully acknowledged. In particular:
Olivier Aubert, Werner Bailer, Pierre-Antoine Champin, Cyril Concolato, Franck Denoual, Martin J. Dürst,
Jean Pierre Evain, Ken Harrenstien, Kilroy Hughes, Philip Jägenstedt, Ryo Kawaguchi, Véronique Malaisé,
Henrik Nordstrom, Yannick Prié, Yves Raimond, Julian Reschke, Geoffrey Sneddon, Felix Sasaki, Philip Taylor,
Christian Timmerer, Jorrit Vermeiren and Munjo Yu.
</p></div><div class="div1">
<h2><a id="change-log" name="change-log" />D Change Log (Non-Normative)</h2><p>@@This paragraph will be replaced by the change log. DO NOT TOUCH@@</p></div></div></body></html>