Re: Discovery of track and named fragment names

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.


Cheers,
Silvia.

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