Re: Discovery of track and named fragment names

Hi Davy,

> To retrieve track and named fragments, we need to know the name of the 
> fragment. Until now, we didn’t talk much about how to discover these 
> names (at client side). When implementing scenarios such as [1], I can 
> image that a certain way of discovering these names will be necessary.

Thanks for bringing up this topic on the table. As Silvia pointed out, 
it has also been quite discussed early in November during both the 
Accessibility workshop held in Stanford [1] and during the Video 
breakout session of the TPAC [2]. I think we could also consider it is 
somehow related to the ISSUE-4 [3] in the tracker. Some comments:

> I implemented, by means of an experiment, the ROE format into our 
> NinSuna platform [4]. More specifically, if you want to get more 
> information regarding the structure of the media resource 
> http://schutz.elis.ugent.be:8080/DownloadServlet/fragf2f.ogv, you can 
> request this resource through HTTP using ‘application/roe’ in the accept 
> header (don’t think this mime type actually exists :-)):

Indeed, no specific mime type for a ROE file seems to have been registered.
Silvia, is http://wiki.xiph.org/index.php/ROE the latest documentation 
available about the ROE format? Do you usually serve such a file with 
the generic xml mime type?

Davy, regarding the ROE file returned:

<ROE xmlns="http://www.xiph.org/roe1.0">
   <body>
     <track id="ogg_1" provides="video">
       <mediaSource id="ogg_1_source" content-type="video/theora" 
src="http://schutz.elis.ugent.be:8080/DownloadServlet/fragf2f.ogv?track='ogg_1'" 
/>
     </track>
     <track id="ogg_2" provides="audio">
       <mediaSource id="ogg_2_source" content-type="audio/vorbis" 
src="http://schutz.elis.ugent.be:8080/DownloadServlet/fragf2f.ogv?track='ogg_2'" 
/>
     </track>
   </body>
</ROE>

Why not returning URI with a '#' instead of a '?':
http://schutz.elis.ugent.be:8080/DownloadServlet/fragf2f.ogv?track='ogg_1'
-->
http://schutz.elis.ugent.be:8080/DownloadServlet/fragf2f.ogv#track='ogg_1' ?

> Any comments on this way of working? Moreover, should we specify a 
> method for discovering track and named fragments as normative in the 
> spec? I think we should have at least an informative section regarding 
> this topic

Thanks for this strawman implementation! And a big +1 to have more 
documentation on this topic in the spec document.
As Sylvia said, I don't think we should necessarily provide a normative 
solution to this problem, but should clearly recognize it and describe 
what are the current solutions on the table: ROE, MPEG-7, MPEG-21 DID, 
Media Annotations API, what else?
I have added an item in the agenda for this week telecon in order to 
discuss how we should move forward for documenting these bits in the 
document ...
Best regards.

   Raphaël

[1] http://www.w3.org/2009/11/01-media-minutes
[2] http://www.w3.org/2009/11/06-video-minutes.html
[3] http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Monday, 23 November 2009 21:28:41 UTC