Silvia.Pfeiffer@csiro.au wrote:> Hi Ian,
>
> CMML is still a draft, so we can change the addressing if required.
> You're correct, currently something like
>
> blah.cmml#fragment
>
> points to a clip (or temporal section) of the stream, but
>
> blah.cmml#t=12
>
> points to a 12 seconds offset.
>
> (same for annodex, i.e. ogg files with skeleton track).
>
>
> For pointing to logical streams inside ogg, I'd really suggest you
> have a look at skeleton. Skeleton has all the information that is
> required, when used with CMML. CMML provides an id tag for each
> logical bitstream that provides a name (in addition to the rather
> arbitrary serial number). Then "id" and the name get encoded in
the
> binary skeleton header as a message header field and can be used for
> addressing. You can use this mechanism also without using CMML, by
> the way.
>
That's interesting thanks. The problem I was approaching (although
I hadn't fully developed it when I posted) is the situation where you
have an XML stream with an id in it and you want to point to that
stream and the id. Now you have two things which are considered
'fragments' and URIs do not have a concept of fragment hierarchy,
though there's nothing to stop an application deciding on one.
The OpenDocument approach to references within a package could work
(relative references without protocol or authority get resolved
within the package tree). So CMML ids referenced from outside behave
the same:
"/blah.cmml#t=12"
(this being an external reference the absolute path is not necessary,
I've added it to distinguish the two cases)
From inside you can just refer to the (physical) stream as a relative
reference:
"#t=12" (12 second offset on whole stream)
The following points to id 'gnats' within named XML (logical) stream
'gnus':
"gnus#gnats"
Like an OpenDocument package the stream-internal id can't be pointed
to from outside although, if your server understood Annodex,
"/example.cmml?id=gnus#gnats" is a possibility.
Because of their nature Annodex/CMML are special: their ids need to be
at file level. Fortunately it wouldn't really make sense to point to
a fragment within an Annodex clip, so the only potential conflict
comes in how you point to the streams themselves.
The alternative is having to allow all ids to be at file level, which
requires you to maintain a list or parse all streams which could
contain ids (and means you have to avoid conflicts).
While serial number is arbitrary I still like it as a lightweight
way of inserting a metadata stream (although maybe a couple of
reserved stream identifiers would serve that purpose?). Skeleton
also has the problem for simple applications that it wants to be
the first page, which will cause libvorbisfile based Ogg/Vorbis
players to choke. Not that libvorbisfile doesn't need to be
updated to play something that isn't strictly Vorbis-I anyway;
but, as it is, players which do return-value checks seem to survive,
as long as they get the Vorbis bos first.
(Sorry if it seems like I'm being awkward, the XML metadata idea
has me wondering about putting arbitrary XML in Ogg. This is
punishment enough: I caught myself wondering if you could actually
put OpenDocument in Ogg given suitable encapsulation for resources.)
> And as for queries: they work with Annodex in the same way that
> fragments work. As per URI standard, the fragments get interpreted
> locally on the client, while the queries can be transported to the
> server and thus perform offset options before streaming.
>
I worked that out on re-reading the RFC, the distinction makes more
sense now.
> I'm not sure if this helps at all since I missed half the discussion.
> But I thought I'd throw in my 5c.
Thanks for the input. It's much appreciated since I'm learning (and
speculating) this as I go along. The half of the discussion you
missed is mainly composed of me rambling to myself.
--
imalone
>
>
> -----Original Message-----
> From: ogg-dev-bounces@xiph.org on behalf of Ian Malone
> Sent: Fri 11/18/2005 3:26 AM
> To: vorbis@xiph.org; ogg-dev@xiph.org
> Cc:
> Subject: [ogg-dev] Re: [Vorbis] metadata
> Ralph Giles wrote:
>
>>On Sun, Oct 02, 2005 at 07:50:25PM +0100, Ian Malone wrote:
>>
>>
>
>
>>>It's not clear to me what the type should be,
>>>"<?xml version='1.0'?>" is clear enough to
determine XML, but the
>>>header should probably indicate the type of stream.
>>
>>
>>Right. The XML declaration provides enough information for a muxer
>>to hand off the stream to an xml parser, analogous to how stream
>>identification can be done with our other codecs. Requiring this
>>should probably be part of a general XML-in-Ogg spec or best
>>practices document.
>>
>>Also having a doctype or namespaced root element in the initial
>>packet to further identify the stream data is, as you suggest,
>>another good idea. I'd make that a SHOULD.
>>
>
>
> CMML may have more on this (a document I should read properly
> sometime), but it seems that a way of specifying a logical stream
> via a URI would be useful too. Within rfc3986 the query or
> fragment components could be used. Both have problems; fragment
> prevents us further specifying a fragment within a logical stream,
> query's meaning seems to be determined by the scheme (also a
> problem with using part of the path). Fragment would also (as I
> understand) conflict with CMML's use, query might conflict.
>
> Another possibility is a scheme solely for use within ogg streams,
> so ogg:6789abcd (the semantics here aren't quite right) is a
> relative reference to the stream with serial:6789abcd. Then
> ogg:6789abcd/#dolphin refers to id=dolphin in that stream,
> ogg:/#dolphin refers to id=dolphin in the physical stream.
> Defining a scheme is probably a long and difficult task, and
> with such limited use it doesn't make much sense (it would
> hardly be uniform).
>
> Query is the most attractive;
> <http://www.example.com/somefile.ogg?serial=6789abcd>
> but I don't yet understand if this is compatible with existing
> uses.
>