similar to: [PATCH] libshout - updated patch for kate and skeleton

ogg.k.ogg.k at googlemail.com wrote: > Hi, > > ACK/NAK on any of those two points (kate support patches and status of > skeleton support) ? > Brendan was the one to working on libshout, but he may be away currently. I can check over it after the dir.xiph.org and icecast updates I have are done. I have not checked over the Kate parts for icecast yet but I don't have a

Hi, the format is now versioned, so I've ported my patches to svn, attached. Also, I noticed, while testing with the latest ffmpeg2theora, which adds a skeleton stream by default, that the resulting video doesn't stream due to that skeleton stream. Is this known, and is there anything planned to add skeleton support ? If not, I might have a go at that too at some point. Cheers

> Can we get confirmation on the player parsing skeleton streams without > issue and are there any cases that should be considered where an > incoming skeleton stream should be filtered for a player connection? If > not then I have no problem with it going in for 2.3.2. I've tried only with xine, with svn icecast and libshout's example client. The stream was skeleton x1,

ogg.k.ogg.k at googlemail.com wrote: > And there they are, with added skeleton support. > While the Kate stuff is tested on various files, the skeleton stuff is > lightly tested > only (on a 7 stream file). Both are rather simple anyway. > > The only thing is I'm not too sure whether the timestamps in the > skeleton headers > should be modified at all for every

Hi, would you be interested in a patch to support kate bitstreams ? Kate is a bitstream format for text data that can be muxed in ogg, here presumably alongside a Theora video. It can be used to carry subtitles, and several separate streams can be muxed concurrently (eg, for subtitles in several languages). More info about Kate can be found there: http://wiki.xiph.org/index.php/OggKate Note

> Right. This was, in fact, one of the roles of "chaining" where you'd > mark such changed components with a chain boundary, at which such > things are explicitly allowed to change. The drawbacks are the > overhead of resending all the setup data for configurable codecs like > vorbis and theora, and the semantic conflict between 'chain boundary > flags an edit

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

On 1/16/08, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Also, it'd likely take a rewrite of oggmerge to make it > usable for multiplexed streams, I think it assumes a single logical stream > per physical stream, though I didn't have an in-depth look at this issue. You are likely correct. > I did see references to Skeleton, I'll have a look at

On Feb 11, 2008 9:27 PM, ogg.k.ogg.k@googlemail.com < ogg.k.ogg.k@googlemail.com> wrote: > > Right. This was, in fact, one of the roles of "chaining" where you'd > > mark such changed components with a chain boundary, at which such > > things are explicitly allowed to change. The drawbacks are the > > overhead of resending all the setup data for

On Jan 17, 2008 2:35 AM, ogg.k.ogg.k@googlemail.com < ogg.k.ogg.k@googlemail.com> wrote: > > > 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

> 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

Hey, On 1/15/08, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > I've now uploaded the preliminary documentation on the xiph wiki: > http://wiki.xiph.org/index.php/OggKate Really nice work, by the way. > 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) I have

On Feb 8, 2008 12:28 AM, ogg.k.ogg.k@googlemail.com < ogg.k.ogg.k@googlemail.com> wrote: > 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

> > 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

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 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 2/8/08, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > 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 stream can't start midway through another

On 21/04/2008, ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com> wrote: > Hi, > > I've added kate support to liboggplay (a prerequisite to getting kate tracks > to work with the mozilla plugin, which I've now got working on Linux). > great! > In addition to the Kate code: > > - a new oggplay-uninstalled.pc file configure.ac:366: required

2008/4/28 ogg.k.ogg.k at googlemail.com <ogg.k.ogg.k at googlemail.com>: > Hi, Hi, I've tried to separate out the general bugfixes from the new implementation work in this patch: > this patch adds: > > - kate support (what else) - this bumps the Javascript API to 1.1 I've not yet committed this to trunk. It does sound pretty cool though. I don't see any problem

If you look at http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions right at the bottom is a description of what the codecs without container format are called. CMML as a timed text codec has a mime type of text/cmml. Similarly, the textual representation of Kate should be text/x-kate. When you encode Kate in Ogg, it would not normally be expected to come without audio or video. Thus, if