[annodex-dev] Timed URI seeking without mod_annodex

[Andre Pang]

On 20/02/2005, at 11:40 AM, Conrad Parker wrote:

> So, seeing as you've decided to put your energy into presupposing this
> particular problem, can you come up with a "serverless" solution that
> isn't too hard for crawlers and random media frameworks to implement
> clientside (ie. you'll provide your simple library in all languages 
> that
> have HTTP modules, right?), ensures that the seektables and the media
> content are consistent, has a mechanism for retrieving CMML, and 
> ensures
> that CMML is consistent with the content? (remember, you're not allowed
> any server-side code to ensure this consistency!) Can you specify that 
> it
> ensures all the fisbone fields are correctly formed after the client
> performs the remux -- ie. you'll get the right set of basegranules, or
> are basegranules suddenly not useful? And so on, and so on -- redesign
> the whole thing, that's what you're asking to do.

Well, the approach that I've always wanted to see is to store the CMML 
in a separate file from the raw media, and having the client always 
"play" the CMML, rather than the media.  This is analagous to HTML, 
which is sometimes self-contained, but often references other media 
(such as JPG images) that are required to successfully display the 
entire page.

Storing the CMML separately has the drawback that now it's not so 
closely associated with the original media, but this is also an 
advantage, since it can be more easily edited.  Again, this is 
analogous to HTML, which can be edited e.g. without "recomposing" the 
HTML page with the other elements required on the page, such as images. 
  It also has the huge advantage that no server-side support is required 
for a search engine to crawl the CMML, and if the seektable idea that 
I've been discussing is used, a client doesn't need any server-side 
support to play the media too.  A dubious bonus is that we also don't 
need to do any extra work to make all this cache-friendly, since the 
client is required to use byte-range combination from the start, rather 
than optionally implementing it.

The major problem I see with this solution is the same as the 
client-side seektable scheme which I've been discussing: where do we 
store the seektable?  Do we expect the raw media file to store it, can 
we store it in the CMML (yecch), or do we put it in another separate 
file again, meaning that we now have the rather inelegant solution of 
three files which need to be moved around to have these features?  I 
was hoping to try to come up with a better solution than any of these 
three when I initiated the discussion.


-- 
: André Pang (x4180)
: Software Engineer, Networked Media : CeNTIE