Re: NinSuna status update

Hi Davy,

On Tue, Sep 29, 2009 at 5:31 PM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
>> -----Original Message-----
>> From: public-media-fragment-request@w3.org [mailto:public-media-
>> fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
>> Sent: dinsdag 29 september 2009 1:20
>> To: Davy Van Deursen
>> Cc: public-media-fragment@w3.org
>> Subject: Re: NinSuna status update
>>
>> Hi Davy,
>>
>> that looks awesome.
>>
>> Do you have a test Web page for these things? If not, I will update
>> the integrated html5 demo page that I wrote recently.
> No, there is no test Web page yet. For the moment, I just provided some
> working example URLs on the Wiki page.

Oh, you really need a nice Web page in HTML5!


>> BTW: Does your client also support he #-based media fragment
>> addressing?
> For the moment, we don't have a client :-). Hence, retrieval of #-based
> media fragment addressed media is not possible yet. However, you can test
> its behavior by sending a Range HTTP request header to our server (e.g., by
> using the Firefox Modify headers add-on [1]). The response (including the
> Content-Range HTTP response header) can then for example be visualized using
> the Firefox Live HTTP headers add-on [2]. But it would indeed be nice to
> have a client that does this behind the scenes.

Nothing to worry about: we can do it with XMLHttpRequest and change
the HTTP headers, I think. So, we should be able to put a normal HTML5
Web page together. I'll see if I can work it out. :-)


>> Another question: when you do the ingest, do you create a special
>> index on the server that supports the retrieval of these byte ranges
>> or do you re-use the existing index in MP4? In Ogg we have recently
>> been discussing a new format for keeping an index of the temporal
>> structure of the Ogg file inside Ogg - possibly in the skeleton
>> header. I just wondered whether you think that would be useful or
>> whether you would always create a separate index file anyway.
>
> We always create our own index. The format of this index is independent of
> any container format. Thus, the same index structure is used for MP4, Ogg,
> etc. The ingester is dependent of the incoming media formats and tries to
> use as many information as possible from the headers provided by the
> incoming media format. Therefore, providing an index of the temporal
> structure within an Ogg file would certainly make the job of our Ogg
> inserter a lot easier ;-).

Work is on its way. The Mozilla video element developers have done
some awesome progress and there may well be an extension to Skeleton
or a new OggIndex track. Not too sure yet. Watch this space!

Cheers,
Silvia.

Received on Tuesday, 29 September 2009 12:39:59 UTC