similar to: Skeletal relations

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

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

Hi, I recognize the main name behind CMML here :) Does the redesigning of CMML allow overlapping clips ? This is the main reason of my current ramblings about seeking. While karaoke was one of the initial goals behind kate, it is just a way the format can be used with (in fact, the format itself does not refer to karaoke at all, but styles and motions). At the moment, it is a fairly versatile

On 16/02/2008, Ralph Giles <giles@xiph.org> wrote: > The general idea is to use the (http-style) Message Headers > in the Skeleton track to describe each logical bitstream, but no one > has ever written anything down. This is a proposal to get the ball > rolling. awesome, thanks :-) > Lang: <locale> generally I think we should go with existing HTTP and email

> Some of the things you talk about were not solved at the CMML level, but > rather through using different Ogg > logical bitstreams. While this is possible to do it this way (and probably a good idea for the examples like a clock in a corner), it implies that all the placements and logically different "items" are known at the start of the stream (since the Ogg spec says a

Hi, A couple of points: 1) Font data, as in the actual font itself, doesn't really belong in an ogg stream. Given that it truly is "global" data in the sense that your fonts are shared by more than just a single ogg file, then the font should be separate from the stream and just referenced using an appropriate font naming scheme. If you meant font references in the first place,

On Thu, Feb 21, 2008 at 9:00 PM, ogg.k.ogg.k@googlemail.com < ogg.k.ogg.k@googlemail.com> wrote: > > If you have an application-specific need for exact font data, then I > think > > the mechanism for retrieving this data should lie in your application, > and > > not in the media format that you're using for media data. I would have > said > > the same

Hi again :) On Wed, Feb 20, 2008 at 9:01 PM, ogg.k.ogg.k@googlemail.com < ogg.k.ogg.k@googlemail.com> wrote: > > 1) Font data, as in the actual font itself, doesn't really belong in an > ogg > > stream. > > People wanting to have more control on the appearance of an overlay > might want to control the font. Since font naming is largely non standard > (eg,

Thanks for the feedback, > I have looked into the patch. It doesn't take into consideration > neither Skeleton, which is used now in pretty much everything encoded > in Ogg (except for single stream Vorbis and Speex files), nor the file > extension for Theora, which is now .ogv. To be honest, I just added Theora because I needed a simple way to multiplex streams. Also, it'd

Hi, I've now uploaded the preliminary documentation on the xiph wiki: http://wiki.xiph.org/index.php/OggKate Attached is the current source tree for the libkate library. The tarball also contains the patch to oggmerge (which you will need to apply if you want to merge Kate streams with Vorbis or Theora streams) and the patch to MPlayer to use Kate streams as subtitles. An example is

> > I did see references to Skeleton, I'll have a look at it. I didn't > > realize it was used widely > > It's not widely used currently. The idea is to make that happen. Oh, I get you now. > CMML does of course other things besides subtitles. Subtitle support > was pretty much just added recently. Kate however does not seem to > offer more than CMML in

I'm trying to create files that contain a video stream, one or more audio streams, subtitles, and DVD-like chapter information. ATM, I use ogm containers that can handle all this. But although ogm is supported e.g. by xine (including chapters), it seems to be an unofficial hack. Is that correct? I'd like to move to ogg containers, since ogm doesn't support theora videos. My final

----- Original Message ----- From: "Ian Malone" <ibmalone@gmail.com> To: <ogg-dev@xiph.org> Sent: Friday, March 10, 2006 8:42 AM Subject: Re: [ogg-dev] oggfile, skeleton and vorbis tools > Re-reading Monty's email: when you talk about vorbis-only vorbisfile and > the concurrent vorbis stream case do you mean vorbisfile will need to be > able to choose?

>> (odd, I did get this reply for Silvia, but not the original post) > > Hmm, it was properly CCed to the list. Yes, I found it in the spam bucket for some reason... > Chapters are a list of timepoints stored in the metadata. They are an > information for player software that is usually used to allow the user > to jump to certain significant points within a stream. This

Hi, (odd, I did get this reply for Silvia, but not the original post) > There is CMML and kate support in vlc, and kate in mplayer though I am > not sure how it is displayed on-screen. Subtitles may display, but > chapter markers, I am not so sure about. Would you mind expanding on what chapters are, and what you'd expect to be able to do with them ? > There is an old python

> If you have an application-specific need for exact font data, then I think > the mechanism for retrieving this data should lie in your application, and > not in the media format that you're using for media data. I would have said > the same thing to Adobe if they'd asked me ;-) We may or may not be talking about the same specific thing. My point was not that there should be

Something which you might also want to consider, unless it is deemed to be outside the scope of skeleton, is a way to embed data that can be referred to by other logical streams, as a means to avoid duplication. A logical stream is self contained as far as the data it handles goes, but several multiplexed streams might need the same, or similar, data. For instance, something I wanted to do was

Daniel, these are all good ideas and worth progressing. However, it may be better not to merge too many goals in one format (MPEG-7 did that and ended up as a big mess). So, I suggest to start by structuring the types of things you want - then finding out which parts belong where into existing formats such as vorbis comment, Skeleton and CMML, and only then start to develop a new format. For

> 1) Font data, as in the actual font itself, doesn't really belong in an ogg > stream. People wanting to have more control on the appearance of an overlay might want to control the font. Since font naming is largely non standard (eg, the foundry etc system (you know, *-*-*-* system) is X only I think, and I think Windows just has filenames), one can't specify a font to use in a

>> I also want to mention that Ogg has a natural chapter mechanism, where >> each chapter is encoded separately and the segments are (literally) >> concatenated together. This is legal as long as the stream serial If the use of these is seeking, chaining doesn't fit the bill as you have to parse the stream to know which chains you have, no ? This kind of defeats the purpose