W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2009

Re: Discovery of track and named fragment names

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 24 Nov 2009 14:58:16 +1100
Message-ID: <2c0e02830911231958tfc584d2yf4d039a3440823eb@mail.gmail.com>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, public-media-fragment@w3.org
Hi Raphel, Davy,

2009/11/24 RaphaŽl Troncy <Raphael.Troncy@cwi.nl>:
>> 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?

ROE isn't registered anywhere and that is indeed the latest
documentation. I believe the only one using it is metavid.

Just use text/x-roe for now if you need a 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' ?

Either should work, I would think.

>> 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?

For HTML5, I am not sure yet that we actually need a description
document. I am currently working on putting a manifest directly into
HTML5, so that would be another means of extracting the information.
However, there would be a mapping between that and the manifest file
formats that your listing here.

I have found that MS if IIS7 have also used a SMIL extract to describe
file manifests - they are called .ism or .ismc files.

Received on Tuesday, 24 November 2009 03:59:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:43 UTC