- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 24 Jun 2010 00:09:53 +1000
- To: Davy Van Deursen <davy.vandeursen@ugent.be>
- Cc: Media Fragment <public-media-fragment@w3.org>
Davy, Did you remove the class of "conditionally fit" altogether? I wonder about your reasons. It's "conditionally fit" formats for which we have introduced many of the server-supported retrieval actions, IMHO. Cheers, Silvia. On Wed, Jun 23, 2010 at 9:43 PM, Davy Vandeursen via cvs-syncmail <cvsmail@w3.org> wrote: > Update of /w3ccvs/WWW/2008/WebVideo/Fragments/WD-media-fragments-reqs > In directory hutz:/tmp/cvs-serv25982 > > Modified Files: > overview.xml > Log Message: > * Added WebM to the list of media formats > * Removed the 'conditionally fit' explanation from the text, since it doesn't make sense anymore with the current spec (i.e., headers are not adapted to the media fragment) > > Index: overview.xml > =================================================================== > RCS file: /w3ccvs/WWW/2008/WebVideo/Fragments/WD-media-fragments-reqs/overview.xml,v > retrieving revision 1.89 > retrieving revision 1.90 > diff -u -d -r1.89 -r1.90 > --- overview.xml 2 Mar 2010 21:46:13 -0000 1.89 > +++ overview.xml 23 Jun 2010 11:43:05 -0000 1.90 > @@ -41,7 +41,7 @@ > <affiliation>EURECOM</affiliation> > </author> > <author> > - <loc href="mailto:erik.mannens@ugent.be"> > + <loc href="http://multimedialab.elis.ugent.be/emannens"> > <name>Erik Mannens</name> > </loc> > <affiliation>IBBT Multimedia Lab, University of Ghent</affiliation> > @@ -67,8 +67,8 @@ > <affiliation>W3C Invited Expert</affiliation> > </author> > <author> > - <loc href="mailto:davy.vandeursen@ugent.be"> > - <name>Davy van Deursen</name> > + <loc href="http://multimedialab.elis.ugent.be/dvdeurse"> > + <name>Davy Van Deursen</name> > </loc> > <affiliation>IBBT Multimedia Lab, University of Ghent</affiliation> > </author> > @@ -629,25 +629,23 @@ > <p> > There is a large number of media codecs and encapsulation formats that we need to take into account as potential media resources on the Web. This section analyses the general conditions for media formats that make them fit for supporting the different types of fragment URIs. > </p> > - <p> > -Media resources should fulfill the following conditions to allow extraction of fragments: > - </p> > - <ulist> > - <item><p>The media fragments can be extracted in the compressed domain.</p></item> > - <item><p>No syntax element modifications in the bitstream are needed to perform the extraction.</p></item> > + <p>The extraction of media fragments from a media resource is possible when these media fragments are extractable in the compressed domain. In other words, media fragments need to be expressable in terms of byte ranges referring to the parent resource. > + Dependent on the fragment axis, there are different requirements regarding the extraction of media fragments (i.e., obtaining media fragments in terms of byte ranges): > + </p> > + <ulist> > + <item><p><em>temporal:</em> random access points need to occur in a regular way (e.g. for video, random access points typically correspond to intra-coded pictures);</p></item> > + <item><p><em>spatial:</em> different regions need to be coded independently from each other;</p></item> > + <item><p><em>track:</em> in contrast to temporal and spatial fragment extraction, tracks are not 'encoded' and can thus always be expressed in terms of byte ranges.</p></item> > </ulist> > - > - <p> > -Not all media formats will be compliant with these two conditions. Hence, we distinguish the following categories: > + <p> > +Not all media formats fullfil all these requirements. Hence, we distinguish the following categories: > </p> > <ulist> > - <item><p><term>Fit</term>: 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 on the byte level is possible.</p></item> > - <item><p><term>Conditionally fit</term>: Media fragments can be extracted in the compressed domain, but syntax element modifications are required. These media fragments provide cacheable byte ranges for the data, but syntax element modifications are needed in headers applying to the whole media resource/fragment. In this case, these headers could be sent to the client in the first response of the server.</p></item> > - <item><p><term>Unfit</term>: Media fragments cannot be extracted in the compressed domain as byte ranges. In this case, transcoding operations are necessary to extract media fragments. Since these media fragments do not create reproducible bytes, it is not possible to cache these media fragments. 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></item> > + <item><p><term>Fit</term>: The media format meets the requirements for one or more axes (i.e., fragments can be extracted in the compressed domain). In this case, caching media fragments of such media resources on the byte level is possible.</p></item> > + <item><p><term>Unfit</term>: Media fragments cannot be extracted in the compressed domain as byte ranges. In this case, transcoding operations are necessary to extract media fragments. Since these media fragments do not create reproducible bytes, it is not possible to cache these media fragments.</p></item> > </ulist> > - > <p> > -Those media types that are capable of doing what server-side media fragments require are of interest to us. For those that aren't, the fall-back case applies (i.e. full download and then offsetting). Appendix <specref ref="fitness-table"/> lists a large number of typical formats and determines which we see fit, conditionally fit, or currently unfit for supporting the different types of media fragment URIs. > +Those media types that are capable of doing what server-side media fragments require are of interest to us. For those that aren't, the fall-back mechanisms apply (e.g., full download and then offsetting). Appendix <specref ref="fitness-table"/> lists a large number of typical formats and determines which we see fit or currently unfit for supporting the different types of media fragment URIs. > </p> > > <ednote> > @@ -827,9 +825,9 @@ > <td>H.264/MPEG-4 AVC</td> > <td>n/a</td> > <td>fit</td> > - <td>conditionally fit</td> > + <td>fit (in theory)</td> > <td>n/a</td> > - <td>Spatial fragment extraction is possible with Flexible Macroblock Ordening (FMO)</td> > + <td>With Flexible Macroblock Ordening (FMO), it is possible to encode spatial regions independently from each other ...</td> > </tr> > <tr> > <td>AVS</td> > @@ -851,9 +849,9 @@ > <td>Motion JPEG2000</td> > <td>n/a</td> > <td>fit</td> > - <td>unfit</td> > + <td>fit</td> > <td>n/a</td> > - <td>Spatial fragment extraction is possible in the compressed domain, but syntax element modifications are needed for every frame.</td> > + <td/> > </tr> > <tr> > <td>VC-1</td> > @@ -882,10 +880,18 @@ > </td> > </tr> > <tr> > + <td>WebM</td> > + <td>n/a</td> > + <td>fit</td> > + <td>unfit</td> > + <td>n/a</td> > + <td/> > + </tr> > + <tr> > <td>RealVideo</td> > <td>n/a</td> > - <td>fit(?)</td> > - <td>unfit(?)</td> > + <td>fit</td> > + <td>unfit</td> > <td>n/a</td> > <td/> > </tr> > @@ -1038,7 +1044,7 @@ > <td>JPEG2000</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td/> > </tr> > @@ -1054,7 +1060,7 @@ > <td>HD Photo</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td/> > </tr> > @@ -1091,98 +1097,98 @@ > </tr> > <tr> > <td>MOV</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td> > <a title="http://www.apple.com/quicktime/tutorials/texttracks.html" class="external text" href="http://www.apple.com/quicktime/tutorials/texttracks.html">QTText</a> provides named chapters > </td> > </tr> > <tr> > <td>MP4</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td> > <a title="http://en.wikipedia.org/wiki/MPEG-4_Part_17" class="external text" href="http://en.wikipedia.org/wiki/MPEG-4_Part_17">MPEG-4 TimedText</a> provides named sections > </td> > </tr> > <tr> > <td>3GP</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td> > <a title="http://en.wikipedia.org/wiki/MPEG-4_Part_17" class="external text" href="http://en.wikipedia.org/wiki/MPEG-4_Part_17">3GPP TimedText</a> provides named sections > </td> > </tr> > <tr> > <td>MPEG-21 FF</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td> > <a title="http://www.chiariglione.org/MPEG/technologies/mp21-did/index.htm" class="external text" href="http://www.chiariglione.org/MPEG/technologies/mp21-did/index.htm">MPEG-21 Digital Item Declaration</a> provides named sections > </td> > </tr> > <tr> > <td>OGG</td> > - <td>conditionally fit (1)</td> > + <td>fit (1)</td> > <td>fit</td> > <td>n/a</td> > - <td>conditionally fit (2)</td> > + <td>fit (2)</td> > <td>(1) Using ROE <bibref ref="roe"/> and Skeleton <bibref ref="skeleton"/>, track selection is possible; (2) Using ROE, CMML <bibref ref="cmml"/> and Skeleton, named addressing of temporal and track fragments is possible > </td> > </tr> > <tr> > <td>Matroska</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td/> > </tr> > <tr> > <td>MXF</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td/> > </tr> > <tr> > <td>ASF</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>Marker objects provide named anchor points</td> > </tr> > <tr> > <td>AVI</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>X</td> > + <td>unfit</td> > <td/> > </tr> > <tr> > <td>FLV</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td> > <a title="http://help.adobe.com/en_US/Soundbooth/2.0/WSA5A1DDFB-6BE2-4486-BE0C-A10CEEF119ADa.html" class="external text" href="http://help.adobe.com/en_US/Soundbooth/2.0/WSA5A1DDFB-6BE2-4486-BE0C-A10CEEF119ADa.html">cue points</a> provide named anchor points > </td> > </tr> > <tr> > <td>RMFF</td> > - <td>fit or conditionally fit(?)</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > <td>?</td> > @@ -1222,10 +1228,10 @@ > </tr> > <tr> > <td>TIFF</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>n/a</td> > <td>n/a</td> > - <td>conditionally fit</td> > + <td>fit</td> > <td>Can store multiple images (i.e., tracks) in one file, possibility to insert "private tags" (i.e., proprietary information)</td> > </tr> > </tbody> > > >
Received on Wednesday, 23 June 2010 14:10:47 UTC