[ogg-dev] Skeletal relations

[Silvia Pfeiffer]

Ralph, Conrad,

Now that we have ROE as a means to describe a multi-track ogg file - i.e. a
means to author Skeleton - I assume this is supposed to describe how we map
ROE information into Skeleton through the use of fisbone message header
fields, right?

In this case I wonder if you have gone over all the current ROE spec and
made sure that all this information is either in ROE or easily extractable
from a logical bitstream? I just wonder if this might expose some unsolved
issues for ROE.

Looking forward reading the full spec, including the mapping.

Cheers,
Silvia.


On Feb 16, 2008 6:35 PM, Ralph Giles <giles at xiph.org> wrote:

> On 15-Feb-08, at 10:11 PM, Conrad Parker wrote:
>
> >>  Lang: <locale>
> >
> > generally I think we should go with existing HTTP and email headers
> > where possible, eg. Content-Language
>
> 'k
>
> >>  Description: <string>
> >
> > I kinda feel that this kind of human-readable metadata better belongs
> > in CMML; the skeleton tells you where to go (for each locale), the
> > CMML has language-specific metadata.
>
> This is fine for the stream as a whole, but I don't see how it helps
> with describing a particular audio track. The idea is that Role (or
> Provides) gives the client software a way to choose directly, and
> Description gives it a way to refine the options it offers the user.
>
> Content-ID: a2
> Content-Type: audio/vorbis
> Content-Language: en
> Provides: Commentary
> Description: Audio Commentary by the Director and Writers
> Description.fr: Le commentaire du metteur en scène
>
> Content-ID: a3
> Content-Type: audio/vorbis
> Content-Language: en
> Provides: Commentary
> Description: Audio Commentary by the Cast
>
> >>  = Relations =
> >>
> >> The value of each of these is an Ogg stream serial number.
> >
> > perhaps an ID (labelled by Content-ID or similar) is more robust.
>
> Right, you mentioned that at LCA, I just forgot.
>
> >>  Substitutes: <serialno>
> >>  Parallels: <serialno>
> >
> > my proposal for these stems from Debian package relationships, where
> > Provides, Depends, Recommends, Suggests, Conflicts are defined locally
> > to each package. In aggregate (considering the whole universe of
> > debian packages) these fields describe the graph of package
> > relationships, but in isolation they are robust in that changes to
> > other packages don't necessarily force a change to the relationship
> > metadata.
>
> Yeah, that part's all good. I look forward to your writeup though,
> because I think the problem space is a little different. Provides
> works as a synonym for Role, but how do you do Overlays?
>
> Content-ID: overlay1
> Role: subtitle
> Overlays: video1
>
> vs
>
> Content-ID: overlay1
> Provides: subtitles
> Depends: video1
>
> I guess it works to make depends a synonym for Overlays. I do like
> Suggests as a way to flag a default configuration.
>
> > In terms of skeleton, two tracks which provide the same thing (eg.
> > subtitles, but in different languages) don't need to contain metadata
> > referencing each other. Instead they simply "Provide: subtitles", and
> > that metadata does not need to be changed if similar tracks are added
> > or removed.
>
> What role does Conflicts have?
>
> >>  Question: Is it better to specify multiple relations with a list of
> >>  serial numbers, or with multiple message headers?
> >
> > these are equivalent, as defined for email/HTTP message headers
> > (multiple message headers can be intercalated with commas).
>
> Ok, thanks.
>
>  -r
> >
>
>
>
> _______________________________________________
> ogg-dev mailing list
> ogg-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/ogg-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080218/67b824d2/attachment.htm