- From: Veronique Malaise <vmalaise@few.vu.nl>
- Date: Fri, 4 Sep 2009 11:09:11 +0200
- To: "Bailer, Werner" <werner.bailer@joanneum.at>
- Cc: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
- Message-Id: <2973EEAB-4423-4D80-A045-2DA7948BB08A@few.vu.nl>
Dear all, I also had a look at the document. I have nothing special to add content-wise, but I would have a remark about the organization of the document: "This specification provides for a media-format independent, standard means of addressing media fragments on the Web using Uniform Resource Identifiers (URI)." I would mention here the fact that this document lists use cases that justify the interest for accessing such media fragments. Otherwise the mention of the use cases arrives a bit late in the document. Generally speaking, an outline of the document could be helpful to explain how the different topics covered relate to each other, as they are quite diverse. Hope that these comments are not totally useless! Nice set of use cases, pretty clear and well defined, otherwise. Best, Véronique On Sep 3, 2009, at 4:08 PM, Bailer, Werner wrote: > Dear all, > > As stated in Tuesday's telecon I reviewed the MFWG use cases and > requirements WD. Please find below my comments (to be merged with > those of other reviewers). > > - 3.6 Singe fragment: Not sure that the term 'mask' is the best > choice here, e.g. in MPEG-7 mask is used for the opposite, i.e. not > a single segment but a segment composed of several unconnected parts. > > - 4.4 Annotating media fragments: A reference to the MAWG > deliverables could be added here. > > - 6.2.1 temporal dimension: Currently on three frame rates are > supported for frame-precise addressing. Especially given the fact > that the HDTV standards include other frame rates (e.g. 24, 50, 60), > which can be expected to be also increasingly available on the web, > it seems useful to adopt a more generic support for frame-precise > addressing (cf. the proposal to use edit units). > > - 6.3.2 track dimension: The restriction to only a single track > seems to be a problem for some of the intended use cases, e.g. > scenario 5 in 4.5.5 mentions that Katrina would like to receive the > original audio + the audio commentary for visually impaired. How > would she request the two tracks? A similar problem is requesting > the video stream + the French audio (but not the English and Spanish > audio, and not the Dutch captions). > > - editorial note in 6.2.3 on track names: MAWG discussed about the > support of fragments in the MAWG API in the F2F in June. One result > was to add a property ma:numTracks which then allow to iterate > through the tracks numerically and query language, format, title (if > supported) for each track fragment. This could be used to construct > appropriate fragment identifiers. > > - 6.4 semantics, editorial note on reasonably close to requested > segment: Returning something close to the requested fragment to > avoid transcoding seems a good choice for use cases like display, > browsing, etc. However, for the recompositing use cases a precise > fragment might be preferred even if it requires transcoding. It > might be an option to include in the request whether the fragment > request is to be interpreted strictly or not. > > Best regards, > Werner > > -------------------------------------------------------------------- > Werner Bailer > Institute of Information Systems > JOANNEUM RESEARCH Forschungsgesellschaft mbH > Steyrergasse 17, A-8010 Graz, AUSTRIA > > phone: +43-316-876-1218 mobile: +43-699-1876-1218 > web: http://www.joanneum.at/iis fax: +43-316-876-1191 > e-mail: mailto:werner.bailer@joanneum.at > -------------------------------------------------------------------- > >
Received on Friday, 4 September 2009 09:10:49 UTC