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