Re: Discovery of track and named fragment names

2009/11/24 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
> 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.

Oh, and OpenCast seem to have something, too
https://wiki.opencastproject.org/confluence/display/open/MediaPackage+Manifest
.

Cheers,
Silvia.

Received on Tuesday, 24 November 2009 04:00:39 UTC