https://wiki.xiph.org/api.php?action=feedcontributions&user=WikiAdmin&feedformat=atomXiphWiki - User contributions [en]2024-03-28T14:37:46ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=FLAC&diff=12872FLAC2011-07-03T15:12:04Z<p>WikiAdmin: </p>
<hr />
<div>'''FLAC''' stands for '''Free Lossless Audio Codec'''. FLAC is an [[wikipedia:audio compression|audio compression]] [[wikipedia:codec|codec]] that is [[wikipedia:lossless data compression|lossless]]. Unlike [[wikipedia:lossy data compression|lossy]] codecs such as [[Vorbis]] and [[wikipedia:MP3|MP3]], it does not remove any information from the audio stream.<br />
<br />
On 2003 January 29th, the [[Xiph.Org Foundation]] announced the incorporation of FLAC under their flag, to go along with Vorbis, [[Theora]], and [[Speex]].<br />
<br />
== The Project ==<br />
<br />
The FLAC project consists of: <br />
* the stream format <br />
* libFLAC, a library of reference encoders and decoders, and a metadata interface <br />
* libFLAC++, an object wrapper around libFLAC <br />
* flac, a command-line wrapper around libFLAC to encode and decode .flac files <br />
* metaflac, a command-line metadata editor for .flac files <br />
* input plugins for various music players ([[wikipedia:Winamp|Winamp]], [[wikipedia:XMMS|XMMS]], [[wikipedia:Foobar2000|foobar2000]], and more in the works)<br />
<br />
"Free" means that the specification of the stream format is in the [[wikipedia:public domain|public domain]] (the FLAC project reserves the right to set the FLAC specification and certify compliance), and that neither the FLAC format nor any of the implemented encoding/decoding methods are covered by any patent. It also means that the sources for libFLAC and libFLAC++ are available under The New BSD license and the sources for flac and metaflac applications, and the plugins are available under the [[wikipedia:GPL|GPL]].<br />
<br />
== Comparisons ==<br />
<br />
FLAC is distinguished from general lossless algorithms such as ZIP and gzip in that it is specifically designed for the efficient packing of audio data; while ZIP may compress a CD-quality audio file 20&ndash;40%, FLAC achieves compression rates of 30&ndash;70%. <br />
<br />
While lossy codecs can achieve ratios of 80&ndash;90+%, they do this at the expense of discarding data from the original stream. Though FLAC uses a similar technique in its encoding process, it also adds "residual" data to allow the decoder to restore the original waveform flawlessly.<br />
<br />
FLAC has become the preferred lossless format for trading live music online. It has a smaller file size than Shorten, and unlike MP3, it's lossless, which ensures the highest fidelity to the source material, which is important to live music traders. It has recently become a favorite trading format of non-live lossless audio traders as well.<br />
<br />
There are other lostless audio codecs, however: WAVPACK (marginally better compression, slower), TAK, Monkey's audio and some more. <br />
<br />
FLAC compiles on many platforms: most Unices (including Linux, *BSD, Solaris, and Mac OS X), DOS, Windows, BeOS, and OS/2. There are build systems for autoconf/automake, MSVC, Watcom C, and Project Builder.<br />
<br />
== More information ==<br />
<br />
* [[FLACDecoders]]: List of decoders<br />
* [[FLACEncoders]]: List of encoders<br />
<br />
== Non-PC playback support ==<br />
<br />
FLAC is supported by a wide range of devices. The [[PortablePlayers#Portable Vorbis Native Support Table|portable players Vorbis support matrix]] also contains information about FLAC support. Other examples of FLAC supporting devices are:<br />
<br />
* [[PortablePlayers/Flash#Cowon.2FiAudio_D2.2C_F2.2C_T2.2C_U3.2C_U2.2C_G3.2C_5.2C_G2.2C_U5.2C_7|iAudio]]: http://www.iaudio.com<br />
* Kenwood Music Keg<br />
* Naim HDX: http://www.naim-audio.com/products/hdx.html<br />
* PhatNoise Home Media Player<br />
* PhatNoise Phatbox<br />
* [[PortablePlayers/Harddisk#Rio Karma|Rio Karma]]: http://www.digitalnetworksna.com/rioaudio/<br />
* [[StaticPlayers#Slim_Devices_Squeezebox.2C_Squeezebox2.2C_Squeezebox3.2C_Transporter|SlimDevices Squeezebox]]: http://www.slimdevices.com<br />
<br />
FLAC is supported by the following chips and/or chipsets:<br />
<br />
* VLSI Solution OY's [http://www.vlsi.fi/en/products/vs1053.html VS1053b] decodes FLAC<br />
<br />
== External links ==<br />
<br />
*[http://flac.sourceforge.net/ Project homepage]<br />
*[http://mikewren.com/flac/ Unofficial FLAC installer for Windows]<br />
*[http://www.danrules.com/macflac/ MacFLAC] [[GUI]] frontend to encode/decode FLAC on [[Mac OS X]]<br />
*[[Wikipedia: FLAC]]<br />
*[http://www.losslessaudioblog.com/ The Lossless Audio Blog] Lossless Audio News & Information Site.<br />
*[http://www.shindiristudio.com/ Web 2.0 Design]<br />
<br />
[[Category:Xiph core projects]]</div>WikiAdminhttps://wiki.xiph.org/index.php?title=Speex&diff=12871Speex2011-07-03T15:10:06Z<p>WikiAdmin: </p>
<hr />
<div>= Website =<br />
<br />
The [http://www.speex.org/ Speex homepage] has all the project info.<br />
<br />
== Hardware ==<br />
<br />
See [[Speex hardware]] for a partial list of supported hardware<br />
<br />
== Tasks ==<br />
<br />
These are some improvements that could be made to Speex. Let [mailto:speex-dev@xiph.org us] know if you'd like to work on one of them.<br />
<br />
* Speech/signal processing (DSP design)<br />
** Improve noise suppression (get rid of musical noise) and residual echo suppression<br />
** Improve packet-loss concealment (PLC)<br />
** Re-write the built-in voice activity detector (VAD)<br />
** Improve the 2.15 kbps vocoder mode (there are even 4 unused bits left to use)<br />
** Algorithmic optimizations (see if some searches can be simplified/approximated)<br />
<br />
* Complete fixed-point (DSP development)<br />
** Wideband<br />
** VBR<br />
** Rest of the narrowband modes<br />
** Preprocessor (noise suppression, AGC)<br />
** Jitter buffer<br />
** Arch-specific optimization<br />
** More...<br />
<br />
* Tune (playing with parameters)<br />
** Noise weighting filter<br />
** Perceptual enhancement<br />
<br />
* Features (plain C programming)<br />
** Implement maximum VBR bit-rate<br />
** Implement peeling (write functions to strip some of the bits)<br />
*** Peel high-band (wideband -> narrowband)<br />
*** Transform 24.6 kbps mode to 15 kbps mode<br />
<br />
* Documentation<br />
** Use questions from the mailing list to create a better FAQ on the wiki<br />
** Update the Speex manual based on recent papers<br />
** Improve libspeex documentation<br />
** Write good example code<br />
<br />
== External links ==<br />
<br />
* [[Wikipedia: Speex]]<br />
* [http://www.shindiristudio.com/ Web Design Studio] <br />
* [http://www.shindiristudio.com/SEO-optimizacija-sajta/ Optimizacija]<br />
<br />
[[Category:Speex]]</div>WikiAdminhttps://wiki.xiph.org/index.php?title=OggKate&diff=12870OggKate2011-07-03T15:08:02Z<p>WikiAdmin: /* Category definition */</p>
<hr />
<div>== Disclaimer ==<br />
This is not a Xiph codec, though it may be embedded in Ogg alonside other Xiph<br />
codecs, such as Vorbis and Theora. As such, please do not assume that Xiph has<br />
anything to do with this, much less responsibility.<br />
<br />
== What is Kate? ==<br />
<br />
Kate is an overlay codec, originally designed for karaoke and text, that can be<br />
multiplixed in Ogg. Text and images can be carried by a Kate stream, and animated.<br />
Most of the time, this would be multiplexed with audio/video to carry subtitles,<br />
song lyrics (with or without karaoke data), etc, but doesn't have to be.<br />
<br />
Series of curves (splines, segments, etc) may be attached to various properties<br />
(text position, font size, etc) to create animated overlays. This allows scrolling<br />
or fading text to be defined. This can even be used to draw arbitrary shapes, so<br />
hand drawing can also be represented by a Kate stream.<br />
<br />
Example uses of Kate streams are movie subtitles for Theora videos, either text based,<br />
as may be created by [http://www.v2v.cc/~j/ffmpeg2theora ffmpeg2theora], or image<br />
based, such as created by [http://thoggen.net Thoggen] (patching needed), and lyrics,<br />
as created by oggenc, from vorbis-tools.<br />
<br />
== Why a new codec? ==<br />
<br />
As I was adding support for Theora, Speex and FLAC to some software of mine, I found myself<br />
wanting to have song lyrics accompanying Vorbis audio. Since Vorbis comments are limited to<br />
the headers, one can't add them in the stream as they are sung, so another multiplexed stream<br />
would be needed to carry them.<br />
<br />
The three possible bases usable for such a codec I found were Writ, CMML, and OGM/SRT.<br />
<br />
*[[OggWrit|Writ]] is an unmaintained start at an implementation of a very basic design, though I did find an encoder/decoder in py-ogg2 later on - I'd been quicker to write Kate from scratch anyway.<br />
*[[CMML]] is more geared towards encapsulating metadata about an accompanying stream, rather than being a data stream itself, and seemed complex for a simple use, though I have now revised my view on this - besides, it seems designed for Annodex (which I haven't had a look at), though it does seems relatively generic for use outwith Annodex - though it is being "repurposed" as timed text now, bringing it closer to what I'm doing<br />
*OGM/SRT, which I only found when I added Kate support to MPlayer, is shoehorning various data formats into an Ogg stream, and just dumps the SRT subtitle format as is, AFAICS (though I haven't looked at this one in detail, since I'd already had a working Kate implementation by that time)<br />
<br />
I then decided to roll my own, not least because it's a fun thing to do.<br />
<br />
I found other formats, such as USF (designed for inclusion in Matroska) and various subtitle formats,<br />
but none were designed for embedding inside an Ogg container.<br />
<br />
== Overview of the Kate bitstream format ==<br />
<br />
I've taken much inspiration from Vorbis and Theora here.<br />
Headers and packets (as well as the API design) follow the design of these two codecs.<br />
<br />
A rough overview (see [[#Format specification|Format specification]] for more details) is:<br />
<br />
Headers packets:<br />
*ID header [BOS]: magic, version, granule fraction, encoding, language, etc<br />
*Comment header: Vorbis comments, as per Vorbis/Theora streams<br />
*Style definitions header: a list of predefined styles to be referred to by data packets<br />
*Region definitions header: a list of predefined regions to be referred to by data packets<br />
*Curves definitions header: a list of predefined curves to be referred to by data packets<br />
*Motion definitions header: a list of predefined motions to be referred to by data packets<br />
*Palette definitions header: a list of predefined palettes to be referred to by data packets<br />
*Bitmap definitions header: a list of predefined bitmaps to be referred to by data packets<br />
*Font mapping definitions header: a list of predefined font mappings to be referred to by data packets<br />
<br />
Other header packets are ignored, and left for future expansion.<br />
<br />
Data packets:<br />
*text data: text/image and optional motions, accompanied by optional overrides for style, region, language, etc<br />
*keepalive: can be emitted at any time to help a demuxer know where we're at, but those packets are optional<br />
*repeats: a verbatim repeat of a text packet's payload, in order to bound any backward seeking needed when starting to play a stream partway through. These are also optional.<br />
*end data [EOS]: marks the end of the stream, it doesn't have any useful payload<br />
<br />
Other data packets are ignored, and left for future expansion.<br />
<br />
The intent of the "keepalive" packet is to be sent at regular<br />
intervals when no other packet has been emitted for a while. This would be to help seeking code<br />
find a kate page more easily.<br />
<br />
Things of note:<br />
*Kate is a discontinuous codec, as defined in [http://www.xiph.org/ogg/doc/ogg-multiplex.html ogg-multiplex.html] in the Ogg documentation, which means it's timed by start granule, not end granule (as Theora and Vorbis).<br />
* All data packets are on their own page, for two reasons:<br />
**Ogg keeps track of granules at the page level, not the packet level<br />
**if no text event happens for a while after a particular text event, we don't want to delay it so a larger page can be issued<br />
<br />
See also [[#Seeking and memory|Problems to solve: Seeking and memory]].<br />
<br />
*The granule encoding is not a direct time/granule correspondance, see the granule encoding section.<br />
*The EOS packet should have a granule pos higher or equal to the end time of all events.<br />
*User code doesn't have to know the number of headers to expect, this is moved inside the library code (as opposed to Vorbis and Theora).<br />
*The format contains hooks so that additional information may be added in future revisions while keeping backward compatibility (though old decoders will correctly parse, but ignore the new information).<br />
<br />
== Format specification ==<br />
<br />
The Kate bitstream format consists of a number of sequential packets.<br />
Packets can be either header packets or data packets. All header packets<br />
must appear before any data packet.<br />
<br />
Header packets must appear in order. Decoding of a data packet is not<br />
possible until all header packets have been decoded.<br />
<br />
Each Kate packet starts with a one byte type. A type with the MSB set<br />
(eg, between 0x80 and 0xff) indicates a header packet, while a type with<br />
the MSB cleared (eg, between 0x00 and 0x7f) indicates a data packet.<br />
All header packets then have the Kate magic, from byte offset 1 to byte<br />
offset 7 ("kate\0\0\0"). Note that this applies only to header packets:<br />
data packets do not contain the Kate signature.<br />
<br />
Since the ID header must appear first, a Kate stream can be recognized<br />
by comparing the first eight bytes of the first packet with the signature<br />
string "\200kate\0\0\0".<br />
<br />
<br />
When embedded in Ogg,the first packet in a Kate stream (always packet type 0x80,<br />
the id header packet) must be placed on a separate page. The corresponding Ogg<br />
packet must be marked as beginning of stream (BOS).All subsequent header packets<br />
must be on one or more pages. Subsequently, each data packet must be on a separate<br />
page.<br />
<br />
The last data packet must be the end of stream packet (packet type 0x7f).<br />
<br />
When embedded in Ogg, the corresponding Ogg packet must be marked as end of stream (EOS).<br />
<br />
As per the Ogg specification, granule positions must be non decreasing<br />
within the stream. Header packets have granule position 0.<br />
<br />
Currently existing packet types are:<br />
:headers:<br />
::0x80 ID header (BOS)<br />
::0x81 Vorbis comment header<br />
::0x82 regions list header<br />
::0x83 styles list header<br />
::0x84 curves list header<br />
::0x85 motions list header<br />
::0x86 palettes list header<br />
::0x87 bitmaps list header<br />
::0x88 font ranges and mappings header<br />
:data:<br />
::0x00 text data (including optional motions and overrides)<br />
::0x01 keepalive<br />
::0x02 repeat<br />
::0x7f end packet (EOS)<br />
<br />
<br />
<br />
This format described here is for bitstream version 0.x.<br />
As or 19 december 2008, the latest bitstream version is 0.4.<br />
<br />
For more detailed information, refer to the format documentation<br />
in libkate (see URL below in the [[#Downloading|Downlading]] section).<br />
<br />
Following is the definition of the ID header (packet type 0x80).<br />
This works out to a 64 byte ID header. This is the header that should be<br />
used to detect a Kate stream within an Ogg stream.<br />
<br />
<br />
<br />
0 1 2 3 |<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| packtype | Identifier char[7]: 'kate\0\0\0' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| kate magic continued | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| reserved - 0 | version major | version minor | num headers | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| text encoding | directionality| reserved - 0 | granule shift | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| cw sh | canvas width | ch sh | canvas height | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| reserved - 0 | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| granule rate numerator | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| granule rate denominator | 28-31<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (NUL terminated) | 32-35<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 36-39<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 40-43<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| language (continued) | 44-47<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (NUL terminated) | 48-51<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 52-55<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 56-59<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| category (continued) | 60-63<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
<br />
The fields cw sh, canvas width, cw sh, and canvas height were introduced<br />
in bistream 0.3. Earlier bitstreams will have 0 in these fields.<br />
<br />
language and category are NUL terminating ASCII strings.<br />
Language follows RFC 3066, though obviously will not accommodate language tags<br />
with lots of subtags.<br />
<br />
Category is currently loosely defined, and I haven't found yet a nice way to<br />
present it in a generic way, but is meant for automatic classifying of<br />
various multiplexed Kate streams (eg, to recognize that some streams are<br />
subtitles (in a set of languages), and some others are commentary (in a<br />
possibly different set of languages, etc).<br />
<br />
== API overview ==<br />
<br />
libkate offers an API very similar to that of libvorbis and libtheora, as well as<br />
an extra higher level decoding API.<br />
<br />
Here's an overview of the three main modules:<br />
<br />
=== Decoding ===<br />
<br />
Decoding is done in a way similar to libvorbis. First, initialize a kate_info and a<br />
kate_comment structure. Then, read headers by calling kate_decode_headerin. Once<br />
all headers have been read, a kate_state is initialized for decoding using kate_decode_init,<br />
and kate_decode_packetin is called repeatedly with data packets. Events (eg, text) can be<br />
retrieved via kate_decode_eventout.<br />
<br />
=== Encoding ===<br />
<br />
Encoding is also done in a way similar to libvorbis. First initialize a kate_info<br />
and a kate_comment structure, and fill them out as needed. kate_encode_headers will<br />
create ogg packets from those. Then, kate_encode_text is called repeatedly for all<br />
the text events to add. When done, calling kate_encode_finish will create an end of<br />
stream packet.<br />
<br />
=== High level decoding API ===<br />
<br />
There are only 3 calls here:<br />
<br />
kate_high_decode_init<br />
kate_high_decode_packetin<br />
kate_high_decode_clear<br />
<br />
Here, all Ogg packets are sent to kate_high_decode_packetin, which does the right<br />
thing (header/data classification, decoding, and event retrieval). Note that you<br />
do not get access to the comments directly using this, but you do get access to the<br />
kate_info via events.<br />
<br />
The libkate distribution includes commented examples for each of those.<br />
<br />
Additionally, libkate includes a layer (liboggkate) to make it easier to use when<br />
embedded in Ogg. While the normal API uses kate_packet structures, liboggkate uses<br />
ogg_packet structures.<br />
<br />
The High level decoding API does not have an Ogg specific layer, but functions exist<br />
to wrap a kate_packet around a memory buffer (such as the one ogg_packet uses, for instance).<br />
<br />
== Support ==<br />
<br />
Among the software with Kate support:<br />
*VLC<br />
*ffmpeg2theora<br />
*liboggz<br />
*liboggplay<br />
*Cortado (wikimedia version)<br />
*vorbis-tools<br />
<br />
I have patches for the following with Kate support:<br />
*MPlayer<br />
*xine<br />
*GStreamer<br />
*Thoggen<br />
*Audacious<br />
*and more...<br />
<br />
These may be found in the libkate source distribution (see [[#Downloading|Downloading]]<br />
for links).<br />
<br />
In addition, libtiger is a rendering library for Kate streams using Pango and Cairo,<br />
though it is not quite yet API stable (though no major changes are expected).<br />
<br />
== Granule encoding ==<br />
<br />
=== Ogg ===<br />
<br />
Ogg leaves the encoding of granules up to a particular codec, only<br />
mandating that granules be non decreasing with time.<br />
<br />
The Kate bitstream format uses a linear mapping between time and<br />
granule, described here.<br />
<br />
A Kate granule position is composed of two different parts:<br />
- a base granule, in the high bits<br />
- a granule offset, in the low bits<br />
<br />
+----------------+----------------+<br />
| base | offset |<br />
+----------------+----------------+<br />
<br />
The number of bits these parts occupy is variable, and each stream<br />
may choose how many bits to dedicate to each. The kate_info structure<br />
for a stream holds that information in the granule_shift field,<br />
so each part may be reconstructed from a granulepos.<br />
<br />
The timestamp T of a given Kate packet is split into a base B and<br />
offset O, and these are stored in the granulepos of that packet.<br />
The split is done such that the B is the time of the earliest event<br />
still active at the time, and the O is the time elapsed between B<br />
and T. Thus, T = B + O. This mimics the way Theora stores its own<br />
timestamps in granulepos, where the base acts as a keyframe, and<br />
an offset acts as the position of an intra frame from the previous<br />
keyframe. Since Kate allows time overlapping events, however, the<br />
choice of the base to use is slightly more complex, as it may not<br />
be the starting time of the previous event, if the stream contains<br />
time overlapping events.<br />
<br />
The kate_info structure for a stream holds a rational fraction<br />
representing the time span of granule units for both the base and<br />
the offset parts.<br />
<br />
The granule rate is defined by the two fields:<br />
<br />
kate_info::gps_numerator<br />
kate_info::gps_denominator<br />
<br />
<br />
The number of bits reserved for the offset is defined by the field:<br />
<br />
kate_info::granule_shift<br />
<br />
=== Generic timing ===<br />
<br />
Kate data packets (data packet type 0) includes timing information (start time,<br />
end time, and time of the earliest event still active). All these are stored as<br />
64 bit at the rate defined by the granule rate, so they do not suffer from the<br />
granule_shift space limitation.<br />
<br />
This also allows for Kate streams to be stored in other containers.<br />
<br />
== Motion ==<br />
<br />
The Kate bitstream format includes motion definition, originally for karaoke purposes, but<br />
which can be used for more general purpose, such as line based drawing, or animation of<br />
the text (position, color, etc)<br />
<br />
Motions are defined by the means of a series of curves (static points, segments, splines (catmull-rom, bezier, and b-splines)).<br />
A 2D point can be obtained from a motion for any timestamp during the lifetime of a text.<br />
This can be used for moving a marker in 2D above the text for karaoke, or to use the x<br />
coordinate to color text when the motion position passes each letter or word, etc.<br />
Motions have an attached semantics so the client code knows how to use a particular motion.<br />
Predefined semantics include text color, text position, etc).<br />
<br />
Since a motion can be composed of an arbitrary number of curves, each of which may have<br />
an arbitrary number of control points, complex motions can be achieved. If the motion is<br />
the main object of an event, it is even possible to have an empty text, and use the motion<br />
as a virtual pencil to draw arbitrary shapes. Even on-the-fly handwriting subtitles could<br />
be done this way, though this would require a lot of control points, and would not be able<br />
to be used with text-to-speech.<br />
<br />
As a proof of concept, I also have a "draw chat" program where two people can draw, and<br />
the shapes are turned to b-splines and sent as a kate motion to be displayed on the other<br />
person's window.<br />
<br />
It is also possible for motions to be discontinuous - simply insert a curve of 'none' type.<br />
While the timestamp lies within such a curve, no 2D point will be generated. This can be<br />
used to temporarily hide a marker, for instance.<br />
<br />
It is worth mentionning that pauses in the motion can be trivially included by inserting<br />
at the right time and for the right duration a simple linear interpolation curve with only<br />
two equal points, equal to the position the motion is supposed to pause at.<br />
<br />
Kate defines a set of predefined mappings so that each decoder user interprets a motion in<br />
the same way. A mapping is coded on 8 bits in the bitstream, and the first 128 are reserved<br />
for Kate, leaving 128 for application specific mappings, to avoid constraining creative uses<br />
of that feature. Predefined mappings include frame (eg, 0-1 points are mapped to the size of<br />
the current video frame), or region, to scale 0-1 to the current region. This allows curves<br />
to be defined without knowing in advance the pixel size of the area it should cover.<br />
<br />
For uses which require more than two coordinates (eg, text color, where 4 (RGBA) values are<br />
needed, Kate predefines the semantics text_color_rg and text_color_ba, so a 4D point can be<br />
obtained using two different motions.<br />
<br />
There are higher level constructs, such as morphing between two styles, or predefined<br />
karaoke effects. More are planned to be added in the future.<br />
<br />
See also [[#Trackers|Trackers]].<br />
<br />
== Trackers ==<br />
<br />
Since attaching motions to text position, etc, makes it hard for the client to keep track of<br />
everything, doing interpolation, etc, the library supplies a tracker object, which handles the<br />
interpolation of the relevant properties.<br />
Once initialized with a text and a set of motions, the client code can give the tracker a new<br />
timestamp, and get back the current text position, text color, etc.<br />
<br />
Using a tracker is not necessary, if one wants to use the motions directly, or just ignore them,<br />
but it makes life easier, especially when considering the the order in which motions are applied<br />
does matter (to be defined formally, but the current source code is informative at this point).<br />
<br />
<br />
== The Kate file format ==<br />
<br />
Though this is not a feature of the bitstream format, I have created a text file format to<br />
describe a series of events to be turned into a Kate bitstream.<br />
At its minimum, the following is a valid input to the encoder:<br />
<br />
: kate {<br />
:: event { 00:00:05 --> 00:00:10 "This is a text" }<br />
: }<br />
<br />
This will create a simple stream with "This is a text" emitted at an offset of 5 seconds into<br />
the track, lasting 5 seconds to an end time at 10 seconds.<br />
<br />
Motions, regions, styles can be declared in a definitions block to be reused by events, or can<br />
be defined inline. Defining those in the definitions block places them in a header so they can<br />
be reused later, saving space. However, they can also be defined in each event, so they will be<br />
sent with the event. This allows them to be generated on the fly (eg, if the bitstream is being<br />
streamed from a realtime input).<br />
<br />
For convenience, the Kate file format also allows C style macros, though without parameters.<br />
<br />
Please note that the Kate file format is fully separate from the Kate bitstream format. The<br />
difference between the two is similar to the difference between a C source file and the resulting<br />
object file, when compiled.<br />
<br />
Note that the format is not based on XML for a very parochial reason: I tend to dislike very<br />
much editing XML by hand, as it's really hard to read. XML is really meant for machines to parse<br />
generically text data in a shared syntax but with possibly unknown semantics, and I need those<br />
text representations to be editable easily.<br />
<br />
This also implies that there could be an XML representation of a Kate stream, which would be<br />
useful if one were to make an editor that worked on a higher level than the current all-text<br />
representation, and it is something that might very well happen in the future, in parallel with<br />
the current format.<br />
<br />
== Karaoke ==<br />
<br />
Karaoke effects rely on motions, and there will be predefined higher level ways of specifying<br />
timings and effects, two of which are already done. As an example, this is a valid Karaoke script:<br />
<br />
:kate {<br />
:: simple_timed_glyph_style_morph {<br />
::: from style "start_style" to style "end_style"<br />
::: "Let " at 1.0<br />
::: "us " at 1.2<br />
::: "sing " at 1.4<br />
::: "to" at 2.0<br />
::: "ge" at 2.5<br />
::: "ther" at 3.0<br />
:: }<br />
:}<br />
<br />
The syllables will change from a style to another as time passes. The definition of the start_style<br />
and end_style styles is omitted for brevity.<br />
<br />
<br />
== Problems to solve ==<br />
<br />
There are a few things to solve before the Kate bitstream format can be considered good<br />
enough to be frozen:<br />
<br />
Note: the following is mostly solved, and the bitstream is now stable, and has been<br />
backward and forward compatible since the first released version. This will be updated<br />
when I get some time.<br />
<br />
=== Seeking and memory ===<br />
<br />
When seeking to a particular time in a movie with subtitles, we may end up at a place when a subtitle has been started, but is not removed yet. Pure streaming doesn't have this problem as it remembers the subtitle being issued (as opposed to, say, Vorbis, for which all data valid now is decoded from the last packet). With Kate, a text string valid now may have been issued long ago.<br />
<br />
I see three possible ways to solve this:<br />
*each data packet includes the granule of the earliest still active packet (if none, this will be the granule of this very packet)<br />
**this means seeks are two phased: first seek, find the next Kate packet, and seek again if the granule of the earlier still active packet is less than the original seeked granule. This implies support code on players to do the double seek.<br />
<br />
*use "reference frames", a bit like Theora does, where the granule position is split in several fields: the higher bits represent a position for the reference frame, and the lowest bits a delta time to the current position. When seeking to a granule position, the lower bits are cleared off, yielding the granule position of the previous reference frame, so the seek ends up at the reference frame. The reference frame is a sync point where any active strings are issued again. This is a variant of the method described in the Writ wiki page, but the granule splitting avoids any "downtime".<br />
**this requires reissuing packets, and it doesn't feel right (and wastes space).<br />
**it also requires "dummy" decoding of Kate data from the reference frame to the actual seek point to fully refresh the state "memory".<br />
<br />
*A variant of the two-granules-in-one system used by libcmml, where the "back link" points to the earliest still active string, rather than the previous one (this allows a two phase seek, rather than a multiphase seek, hopping back from event to event, with no real way to know if there is or not a previous event which is still active - I suppose CMML has no need to know this, if their "clips" do not overlap - mine can do).<br />
**Such a system considerably shortens the usable granule space, though it can do a one phase seek, if I understand the system correctly, which I am not certain.<br />
*** Well, it seems it can't do a one phase seek anyway.<br />
<br />
*Additionally, it could be possible to emit simple "keepalive" packets at regular intervals to help a seek algorithm to sync up to the stream without needing too much data reading - this helps for discontinuous streams where there could be no pages for a while if no data is needed at that time.<br />
<br />
=== Text encoding ===<br />
<br />
A header field declares the text encoding used in the stream. At the moment, only UTF-8 is<br />
supported, for simplicity. There are no plans to support other encodings, such as UTF-16,<br />
at the moment.<br />
<br />
Note that strings included in the header (language, category) are not affected by that<br />
language encoding (rather obviously for language itself). These are ASCII.<br />
<br />
The actual text in events may include simple HTML-like markup (at the moment, allowed markup<br />
is the same as the one Pango uses, but more markup types may be defined in the future).<br />
It is also possible to ask libkate to remove this markup if the client prefers to receive<br />
plain text without the markup.<br />
<br />
=== Language encoding ===<br />
<br />
A header field defines the language (if any) used in the stream (this can be overridden in a<br />
data packet, but this is not relevant to this point). At the moment, my test code uses<br />
ISO 639-1 two letter codes, but I originally thought to use RFC 3066 tags. However, matching<br />
a language to a user selection may be simpler for user code if the language encoding is kept<br />
simple. At the moment, I tend to favor allowing both two letter tags (eg, "en") and secondary<br />
tags (like "en_EN"), as RFC 3066 tags can be quite complex, but I welcome comments on this.<br />
<br />
If a stream contains more than one language, there usually is a predominant language, which<br />
can be set as the default language for the stream. Each event can then have a language<br />
override. If there is no predominant language, and it is not possible to split the stream<br />
into multiple substreams, each with its own language, then it is possible to use the "mul"<br />
language tag, as a last resort.<br />
<br />
=== Bitstream format for floating point values ===<br />
<br />
Floating point values are be turned to a 16.16 fixed point format, then stored in a bitpacked<br />
format, storing the number of zero bits at the head and tail of the floating point values once<br />
per stream, and the remainder bits for all values in the stream. This seems to yield good results<br />
(typically a 50% reduction over 32 bits raw writes, and 70% over the snprintf based storage), and<br />
has the big advantage of being portable (eg, independant of any IEEE format).<br />
However, this means reduced precision due to the quantization to 16.16. I may add support for<br />
variable precision (eg, 8.24 fixed point formats) to alleviate this. This would however mean less<br />
space savings, though these are likely to be insignificant when Kate streams are interleaved with<br />
a video.<br />
<br />
*Though this is not a Kate issue per se, the motion feature is very difficult to use without a curve editor. While tools may be coded to create a Kate bitstream for various existing subtitle formats, it is not certain it will be easy to find a good authoring tool for a series of curves. That said, it's not exactly difficult to do if you know a widget set.<br />
<br />
=== Higher dimensional curves/motions ===<br />
<br />
It is quite annoying to have to create two motions to control a color change, due to curves<br />
being restricted to two dimensions. I may add support for arbitrary dimensions. It would also<br />
help for 1D motions, like changing the time flow, where one coordinate is simply ignored at<br />
the moment.<br />
Alternatively, changes could be made to the Kate file format to hide the two dimensionality and<br />
allow simpler specification of non-2 dimensional motions, but still map them to 2D in the kate<br />
bitstream format.<br />
<br />
=== Category definition ===<br />
<br />
The category field in the BOS packet is a 16 byte text field (15 really, as it is zero terminated<br />
in the bitstream itself). Its goal is to provide the reader with a short description of what kind<br />
of [http://www.shindiristudio.com/ web design] information the stream contains, eg subtitles, lyrics, etc. This would be displayed to the user,<br />
possibly to allow to choose to turn some streams on and off.<br />
<br />
Since this category is meant primarily for a machine to parse, they will be kept to ASCII. When<br />
a player recognizes a category, it is free to replace its name with one in the user's language if<br />
it prefers. Even in English, the "lyrics" category could be displayed by a player as "Lyrics".<br />
<br />
Since this is a free text field rather than an enumeration, it would be good to have a list of<br />
common predefined category names that Kate streams can use.<br />
<br />
This is a list of proposed predefined categories, feedback/additions welcome:<br />
<br />
* subtitles - the usual movie subtitles, as text<br />
* spu-subtitles - movie subtitles in DVD style paletted images<br />
* lyrics - song lyrics<br />
<br />
Please remember the 15 character limit if proposing other categories.<br />
<br />
Note that the list of categories is subject to change, and will likely<br />
be replaced by new, more "identifier like" ones. The three ones above,<br />
however, would be kept for backward compatibility as they're already used.<br />
<br />
== Text to speech ==<br />
<br />
One of the goals of the Kate bitstream format is that text data can be easily parsed<br />
by the user of the decoder, so any additional information, such as style, placement,<br />
karaoke data, etc, should be able to be stripped to leave only the bare text. This is<br />
in view of allowing text-to-speech software to use Kate bitstreams as a bandwith-cheap<br />
way of conveying speech data, and could also allow things like e-books which can be<br />
either read or listened to from the same bitstream (I have seen no reference to this<br />
being used anywhere, but I see no reason why the granule progression should be temporal,<br />
and not user controlled, such as by using a "next" button which would bump a granule<br />
postion by a preset amount, simulating turning a page (this would be close to necessary<br />
for text-to-speech, as the wall time duration of the spoken speech is not known in<br />
advance to the Kate encoder, and can't be mapped to a time based granule progression)).<br />
All text strings triggered consecutively between the two granule positions would then<br />
be read in order.<br />
<br />
== Possible additions ==<br />
<br />
=== Embedded binary data ===<br />
<br />
Images and font mappings can be included within a Kate stream.<br />
<br />
==== Images ====<br />
<br />
Though this could be misused to interfere with ability to render as text-to-speech, Kate<br />
can use images as well as text. The same caveat as for fonts applies with regard to data<br />
duplication.<br />
<br />
Complex images might however be best left to a multiplexed OggSpots or OggMNG stream, unless the<br />
images mesh with the text (eg, graphical exclamation points, custom fonts, (see next<br />
paragraph), etc).<br />
<br />
There is support for simple paletted bitmap images, with a variable length palette of up<br />
to 256 colors (in fact, sized in powers of 2 up to 256) and matching pixel data in as<br />
many bits per pixel as can address the palette. Palettes and images are stored separately,<br />
so can be used with one another with no fixed assignment.<br />
<br />
Palettes and bitmaps are put in two separate header for later use by reference, but can<br />
also be placed in data packets, as with motions, etc, if they are not going to be reused.<br />
<br />
PNG bitmaps can also be embedded in a Kate stream. These do not have associated palettes<br />
(but the PNGs themselves may or may not be paletted). There is no support for decoding PNG<br />
images in libkate itself, so a program will have to use libpng (or similar code) to decode<br />
the PNG image. For instance, the libtiger rendering library uses Cairo to decode and render<br />
PNG images in Kate streams.<br />
<br />
This can be used to have custom fonts, so that raw text is still available if the stream<br />
creator wants a custom look.<br />
<br />
I expect that the need for more than 256 colors in a bitmap, or non palette bitmap data,<br />
would be best handled by another codec, eg OggMNG or OggSpots. The goal of images in a<br />
Kate stream is to mesh the images with the text, not to have large images by themselves.<br />
<br />
On the other hand, interesting Karaoke effects could be achieved by having MNG images<br />
instead of simple paletted bitmaps in a Kate streams. Comments would be most welcome on<br />
whether this is going too far, however.<br />
<br />
I am also investigating SVG images. These allow for very small footprint images for simple<br />
vector drawings, and could be very useful for things like background gradients below text.<br />
<br />
A possible solution to the duplication issue is to have another stream in the container<br />
stream, which would hold the shared data (eg, fonts), which the user program could load,<br />
and which could then be used by any Kate (and other) stream. Typically, this type of stream<br />
would be a degenerate stream with only header packets (so it is fully processed before any<br />
other stream presents data packets that might make use of that shared data), and all payload<br />
such as fonts being contained within the headers. Thinking about it, it has parallels with<br />
the way Vorbis stores its codebooks within a header packet, or even the way Kate stores the<br />
list of styles within a header packet.<br />
<br />
==== Fonts ====<br />
<br />
Custom fonts are merely a set of ranges mapping unicode code points to bitmaps. As this implies,<br />
fonts are bitmap fonts, not vector fonts, so scaling, if supported by the rendering client,<br />
may not look as good as with a vector font.<br />
<br />
A style may also refer to a font name to use (eg, "Tahoma"). These fonts may or may not be<br />
available on the playing system, however, since the font data is not included in the stream,<br />
just referenced by name. For this reason, it is best to keep to widely known fonts.<br />
<br />
== Reference encoder/decoder ==<br />
<br />
A encoder (kateenc) and a decoder (katedec) are included in the tools directory.<br />
The encoder supports input from several different formats:<br />
* a custom text based file format (see [[#The Kate file format|The Kate file format]]), which is by no means meant to be part of the Kate bitstream specification itself<br />
* SubRip (.srt), the most common subtitle format I found<br />
* LRC lyrics format.<br />
<br />
As an example for the widely used SRT subtitles format, the following command line<br />
create a Kate subtitles stream from an SRT file:<br />
<br />
kateenc -l en -c subtitles -t srt -o subtites.ogg subtitles.srt<br />
<br />
The reverse is possible, to recover an SRT file from a Kate stream, with katedec.<br />
<br />
Note that the subtitles.ogg file should then be multiplexed into the A/V stream,<br />
using either ogg-tools or oggz-tools.<br />
<br />
The Kate bitstreams encoded and decoded by those tools are (supposed to be) correct for this<br />
specification, provided their input is correct.<br />
<br />
== Next steps ==<br />
<br />
=== Continuations ===<br />
<br />
Continuations are a way to add to existing events, and are mostly meant for motions. When streaming<br />
in real time, what motions may be applied to events may not be known in advance (for instance, for a<br />
draw chat program where two programs exchange Kate streams, the drawing motions are only known as<br />
they are drawn. Continuations will allow an event to be extended in time, and motions to be appended<br />
to it. This is only useful for streaming, as when stored in a file, everything is already known in<br />
advance.<br />
<br />
=== A rendering library ===<br />
<br />
This will allow easier integration in other packages (movie players, etc).<br />
I have started working on an implementation using Cairo and Pango, though I'm still at the early stages.<br />
I might add support for embedding vector fonts in a Kate stream if I was going that way. Still need to think about this.<br />
Another point of note is that when this library is available, it would make it easier to add<br />
capabilities such as rotation, scaling, etc, to the bitstream, since this would not cause too<br />
much work for playing programs using the rendering library. It is expected that these additions<br />
would stay backward compatible (eg, an old player would ignore this information but still correctly<br />
decode the information they can work with from a newly encoded stream).<br />
<br />
=== An XML representation ===<br />
<br />
While I purposefully did not write Kate description files in XML due to me finding editing XML such<br />
a chore, it would be nice to be able to losslessly convert between the more user friendly representation<br />
and an XML document, so one can do what one does with XML documents, like transformations.<br />
<br />
And after all, some people might prefer editing the XML version.<br />
<br />
=== Packaging ===<br />
<br />
It would be really nice to have packages for libkate/libtiger for many distros.<br />
<br />
If you're a packager for a distro which doesn't have yet packages for libkate<br />
or libtiger, please consider helping :)<br />
<br />
In particular, packages for Debian would be grand.<br />
<br />
== Matroska mapping ==<br />
<br />
The codec ID is "S_KATE".<br />
<br />
As for Theora and Vorbis, Kate headers are stored in the private data as xiph-laced packets:<br />
<br />
Byte 0: number of packets present, minus 1 (there must be at least one packet) - let this number be NP<br />
Bytes 1..n: lengths of the first NP packets, coded in xiph style lacing<br />
Bytes n+1..end: the data packets themselves concatenated one after the other<br />
<br />
Note that the length of the last packet isn't encoded, it is deduced from the sizes of the other<br />
packets and the total size of the private data.<br />
<br />
This mapping is similar to the Vorbis and Theora mappings, with the caveat that one should not<br />
expect a set number of headers.<br />
<br />
== Downloading ==<br />
<br />
libkate encodes and decodes Kate streams, and is API and ABI stable.<br />
<br />
The libkate source distribution is available at [http://libkate.googlecode.com/ http://libkate.googlecode.com/].<br />
<br />
A public git repository is available at [http://git.xiph.org/?p=users/oggk/kate.git;a=summary http://git.xiph.org/?p=users/oggk/kate.git;a=summary].<br />
<br />
libtiger renders Kate streams using Pango and Cairo, and is alpha, with API changes still possible.<br />
<br />
The libtiger source distribution is available at [http://libtiger.googlecode.com/ http://libtiger.googlecode.com/].<br />
<br />
A public git repository is available at [http://git.xiph.org/?p=users/oggk/tiger.git;a=summary http://git.xiph.org/?p=users/oggk/tiger.git;a=summary].<br />
<br />
== HOWTOs ==<br />
<br />
These paragraphs describe a few ways to use Kate streams:<br />
<br />
=== Text movie subtitles ===<br />
<br />
Kate streams can carry Unicode text (that is, text that can represent<br />
pretty much any existing language/script). If several Kate streams are<br />
multiplexed along with a video, subtitles in various languages can be<br />
made for that movie.<br />
<br />
An easy way to create such subtitles is to use ffmpeg2theora, which<br />
can create Kate streams from SubRip (.srt) format files, a simple but<br />
common text subtitles format. ffmpeg2theora 0.21 or later is needed.<br />
<br />
At its simplest:<br />
<br />
ffmpeg2theora -o video-with-subtitles.ogg --subtitles subtitles.srt<br />
video-without-subtitles.avi<br />
<br />
Several languages may be created and tagged with their language code<br />
for easy selection in a media player:<br />
<br />
ffmpeg2theora -o video-with-subtitles.ogg video-without-subtitles.avi<br />
--subtitles japanese-subtitles.srt --subtitles-language ja<br />
--subtitles welsh-subtitles.srt --subtitles-language cy<br />
--subtitles english-subtitles.srt --subtitles-language en_GB<br />
<br />
Alternatively, kateenc (which comes with the libkate distribution) can<br />
create Kate streams from SubRip files as well. These can then be merged<br />
with a video with oggz-tools:<br />
<br />
kateenc -t srt -c SUB -l it -o subtitles.ogg italian-subtitles.srt<br />
oggz merge -o movie-with-subtitles.ogg movie-without-subtitles.ogg subtitles.ogg<br />
<br />
This second method can also be used to add subtitles to a video which<br />
is already encoded to Theora, as it will not transcode the video again.<br />
<br />
<br />
=== DVD subtitles ===<br />
<br />
DVD subtitles are not text, but images. Thoggen, a DVD ripper program,<br />
can convert these subtitles to Kate streams (at the time of writing,<br />
Thoggen and GStreamer have not applied the necessary patches for this<br />
to be possible out of the box, so patching them will be required).<br />
<br />
When configuring how to rip DVD tracks, any subtitles will be detected<br />
by Thoggen, and selecting them in the GUI will cause them to be saved as<br />
Kate tracks along with the movie.<br />
<br />
<br />
=== Song lyrics ===<br />
<br />
Kate streams carrying song lyrics can be embedded in an Ogg file. The<br />
oggenc Vorbis encoding tool from the Xiph.Org Vorbis tools allows lyrics<br />
to be loaded from a LRC or SRT text file and converted to a Kate stream<br />
multiplexed with the resulting Vorbis audio. At the time of writing,<br />
the patch to oggenc was not applied yet, so it will have to be patched<br />
manually with the patch found in the diffs directory.<br />
<br />
oggenc -o song-with-lyrics.ogg --lyrics lyrics.lrc --lyrics-language en_US song.wav<br />
<br />
So called 'enhanced LRC' files (containing extra karaoke timing information)<br />
are supported, and a simple karaoke color change scheme will be saved<br />
out for these files. For more complex karaoke effects (such as more <br />
complex style changes, or sprite animation), kateenc should be used with<br />
a Kate description file to create a separate Kate stream, which can then<br />
be merged with a Vorbis only song with oggz-tools:<br />
<br />
oggenc -o song.ogg song.wav<br />
kateenc -t kate -c LRC -l en_US -o lyrics.ogg lyrics-with-karaoke.kate<br />
oggz merge -o song-with-karaoke.ogg lyrics-with-karaoke.ogg song.ogg<br />
<br />
This latter method may also be used if you already have an encoded Vorbis song<br />
with no lyrics, and just want to add the lyrics without reencoding.<br />
<br />
<br />
=== Changing a Kate stream embedded in an Ogg stream ===<br />
<br />
If you need to change a Kate stream already embedded in an Ogg stream (eg, you have a movie with subtitles, and you want to fix a spelling mistake, or want to bring one of the subtitles forward in time, etc), you can do this easily with KateDJ, a tool that will extract Kate streams, decode them to a temporary location, and rebuild the original stream after you've made whatever changes you want.<br />
<br />
KateDJ (included with the libkate distribution) is a GUI program using wxPython, a Python module for the wxWidgets GUI library, and the oggz tools (both needing installing separately if they are not already).<br />
<br />
The procedure consists of:<br />
<br />
* Run KateDJ<br />
* Click 'Load Ogg stream' and select the file to load<br />
* Click 'Demux file' to decode Kate streams in a temporary location<br />
* Edit the Kate streams (a message box tells you where they are placed)<br />
* When done, click 'Remux file from parts'<br />
* If any errors are reported, continue editing until the remux step succeeds<br />
<br />
== Frequently Asked Questions ==<br />
<br />
=== Does libkate work on other plaforms than Linux ? ===<br />
<br />
Yes, libkate is not Linux specific in any way. It optionally relies on libogg<br />
and libpng, two libraries widely ported to various platforms.<br />
It has been reported to work on Windows and MacOS X as well as UNIX platforms.<br />
<br />
However, libtiger, a rendering library for Kate streams, relies on Pango and Cairo,<br />
which are not easy to build on Windows, though they can be.<br />
The Tiger renderer is however completely separate from libkate, and is not needed<br />
for full encoding and decoding of Kate streams.<br />
<br />
=== Where can I find some example files ? ===<br />
<br />
The libkate distribution can generate various examples, but already built files<br />
can be found there:<br />
[http://people.xiph.org/~oggk/elephants_dream/elephantsdream-with-subtitles.ogg]<br />
[http://stallman.org/fry/Stephen_Fry-Happy_Birthday_GNU-nq_600px_425kbit.ogv]<br />
<br />
These files use raw text only.<br />
<br />
<br />
<br />
[[Category:Drafts]]<br />
[[Category:Ogg Mappings]]</div>WikiAdminhttps://wiki.xiph.org/index.php?title=CMML&diff=12869CMML2011-07-03T15:05:31Z<p>WikiAdmin: </p>
<hr />
<div>'''CMML''' stands for <b>Continuous Media Markup Language</b> and is to audio or video what HTML is to text. CMML is essentially a timed text codec. It allows to structure a time-continuously sampled data file by dividing it into temporal sections (so-called <i>clips</i>) and provides these clips with some additional information. This information is HTML-like and is essentially a textual representation of the audio or video file. CMML enables textual searches on these otherwise binary files.<br />
<br />
CMML is appropriate for use with all [[Ogg]] media formats, to provide subtitles and timed metadata. This description gives a quick introduction only and explains how to map CMML into Ogg. For full specifications, see [http://www.annodex.net/specifications.html http://www.annodex.net/specifications.html].<br />
<br />
<br />
== CMML specification ==<br />
<br />
Before describing the actual data that goes into a logical Ogg bitstream, we need to understand what the stand-alone "codec" packets contains.<br />
<br />
CMML basically consists of:<br />
<br />
* a <b>head</b> tag which contains information for the complete audio/video file<br />
* a set of <b>clip</b> tags which each contains information on a temporal section of the file<br />
* for authoring purposes, CMML also allows a <b>stream</b> tag which spcifies the file it describes<br />
<br />
An example CMML file looks like this:<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><br />
<!DOCTYPE cmml SYSTEM "cmml.dtd"><br />
<br />
<cmml lang="en" id="simple" granulerate="1000/1"><br />
<br />
<stream id="fish" basetime="0"><br />
<import id="videosrc" lang="en" title="Video fish" <br />
granulerate="25/1" contenttype="video/ogg" <br />
src="fish.ogv" start="0" end="360"><br />
<param id="vheight" name="video.height" value="250"/><br />
<param id="vwidth" name="video.width" value="180"/><br />
</import><br />
</stream><br />
<br />
<head><br />
<title>Types of fish</title><br />
<meta name="Producer" content="Joe Ordinary"/><br />
<meta name="DC.Author" content="Joe's friend"/><br />
</head><br />
<br />
<clip id="intro" start="0"><br />
<a href="http://www.example.com/fish.html">Read more about fish</a><br />
<desc>This is the introduction to the film Joe made about fish.</desc><br />
</clip><br />
<br />
<clip id="dolphin" start="npt:3.5" end="npt:5:5.9"><br />
<img src="dolphin.jpg"/><br />
<desc>Here, Joe caught sight of a dolphin in the ocean.</desc><br />
<meta name="Subject" content="dolphin"/><br />
</clip><br />
<br />
<clip id="goldfish" start="npt:5:5.9"><br />
<a href="http://www.example.com/morefish.anx?id=goldfish">More video clips on goldfish.</a><br />
<img src="http://www.example.com/goldfish.jpg"/><br />
<desc>Joe has a fishtank at home with many colourful fish. The common goldfish is one of them and Joe's favourite.<br />
Here are some fabulous pictures he has taken of them.</desc><br />
<meta name="Location" content="Joe's fishtank"/><br />
<meta name="Subject" content="goldfish"/><br />
</clip><br />
<br />
</cmml><br />
</pre><br />
<br />
<br />
The head element is a standard head element from html.<br />
<br />
Clips contain (amongst others) the following information:<br />
<br />
* a name in the <b>id</b> attribute so addressing of the clips is possible, as in http://www.example.com/morefish.anx?id=goldfish (Web server needs to [http://annodex.net/software/mod_annodex/ support] this)<br />
* a <b>start</b> and possibly an <b>end</b> attribute, to tell the clip where it is temporally located<br />
* a <b>title</b> attribute to give it a short description<br />
* <b>meta</b> elements to provide it with structed meta data as name-value pairs<br />
* a <b>img</b> element which links to a picture that represents the content of the clip visually<br />
* a <b>a</b> element which puts a hyperlink to another Web resource into the clip<br />
* a <b>desc</b> element giving a long, free-text description/annotation/transcription for the clip<br />
<br />
Most of this information is optional.<br />
<br />
== CMML mapping into Ogg ==<br />
<br />
When CMML is mapped into an Ogg logical bitstream it needs to be serialised first. XML is a hierarchical file format, so is not generally serialisable. However, CMML has been designed to be serialised easily.<br />
<br />
CMML is serialised by having some initial header packets that set up the CMML decoding environment, and contain header type information. The content packets of a CMML logical bitstream then consists of <b>clip</b> tags only. The <b>stream</b> tag is not copied into the CMML bitstream as it controls the authoring only.<br />
<br />
All of the CMML bitstream information is text. As it gets encoded into a binary bitstream, an encoding format has to be specified. To simplify things, UTF-8 is defined as the mandatory encoding format for all data in a CMML binary bitstream. Also, the encoding process MUST ensure that newline characters are represented as LF (or "\n" in C) only and replace any new line representations that come as CR LF combinations (or "\r\n" in C) with LF only.<br />
<br />
The media mapping for CMML into Ogg is as follows:<br />
* The bos page contains a CMML ident packet.<br />
* The first secondary header packet of CMML contains the xml preamble.<br />
* The second secondary header packet contains the CMML "head" tag.<br />
* The content or data packets for CMML contain the CMML "clip" tags each encoded in their own packet and inserted at the accurate time.<br />
* The eos page contains a packet with an empty clip tag.<br />
<br />
<br />
=== The CMML ident header packet ===<br />
<br />
The CMML logical bitstream starts with an ident header which is encapsulated into the CMML bos page. The ident header contains all information required to identify the CMML bitstream and to set up a CMML decoder. It has the following format:<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Identifier 'CMML\0\0\0\0' | 0-3<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 4-7<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Version major | Version minor | 8-11<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granulerate numerator | 12-15<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 16-19<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granulerate denominator | 20-23<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| | 24-27<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| Granuleshift | 28<br />
+-+-+-+-+-+-+-+-+<br />
| ...<br />
<br />
The CMML <i>version</i> as described here is major=2 minor=1.<br />
<br />
The <i>granulerate</i> represents the temporal resolution of the logical bitstream in Hz given as a rational number in the same way as the [[OggSkeleton]] fisbone secondary header specifies granulerate. It enables a mapping of granule position of the data pages to time by calculating "granulepos / granulerate".<br />
<br />
The default granule rate for CMML is: 1/1000.<br />
<br />
The <i>granuleshift</i> is a 1 Byte integer number describing whether to partition the granule_position into two for the CMML logical bitstream, and how many of the lower bits to use for the partitioning. The upper bits then still signify a time-continuous granule position for a directly decodable and presentable data granule. The lower bits allow for specification of the granule position of a previous CMML data packet (i.e. "clip" element), which helps to identify how much backwards seeking is necessary to get to the last and still active "clip" element (of the given track). The granuleshift is therefore the log of the maximum possible clip spacing.<br />
<br />
The default granule shift used is 32, which halfs the granule position to allow for the backwards pointer.<br />
<br />
=== The CMML secondary header packets ===<br />
<br />
The CMML secondary headers are a sequence of two packets that contain the CMML and XML "setup" information:<br />
* one packet with the CMML xml preamble and <b>cmml</b> tag.<br />
* one packet with the CMML <b>head</b> tag.<br />
<br />
These packets contain textual, not binary information.<br />
<br />
The CMML preamble tags are all single-line tags, such as the xml processing instruction (<?xml...>) and the document type declaration (<!DOCTYPE...>).<br />
<br />
The only CMML tag that is not already serialized from a CMML file is the <b>cmml</b> tag, as it encloses all the other content tags. To serialise it, the <b>cmml</b> start tag is transformed into a processing instruction, retaining all its attributes (<?cmml ...>), and the <b>cmml</b> end tag is deleted.<br />
<br />
The first CMML secondary header packet has the following format:<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <?xml ... | 0-<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <!DOCTYPE ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <?cmml ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
The second CMML secondary header packet contains the CMML <b>head</b> element with all its attributes and other containing elements and has the following format.<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <head ... | 0-<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| </head> |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
=== The CMML data packets ===<br />
<br />
The data packets of the CMML bitstream contain the CMML <b>clip</b> elements. Their <b>start</b> and <b>end</b> attributes however only exist for authoring purposes and are not copied into the bitstream (to avoid contradictory information), but are rather represented through the time mapping of the encapsulation format that interleaves CMML data with data from other time-continuous bitstreams. Generally the time mapping is done through some timestamp representation and through the position in the stream.<br />
<br />
A <b>clip</b> tag is encoded with all tags (except for the <b>start</b> and <b>end</b> attributes) as a string printed into a clip packet. The <b>clip</b> tag's <b>start</b> attribute tells the encapsulator at what time to insert the clip packet into the bitstream. If an <b>end</b> attribute is present, it leads to the creation of another clip packet, unless another clip packet starts on the same track beforehand. This clip packet contains an "empty" <b>clip</b> tag, i.e. a <b>clip</b> tag without <b>meta</b>, <b>a</b>, <b>img</b> or <b>desc</b> elements and no attribute values except for a copy of the <b>track</b> attribute from the original <b>clip</b> tag.<br />
<br />
0 1 2 3<br />
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| <clip ... | 0-<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| ... |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
| </clip> |<br />
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br />
<br />
<br />
== Development ==<br />
<br />
Ogg CMML is being supported by the following projects:<br />
* the Ogg Directshow filters: see [http://www.illiminable.com/ogg/ illiminable]<br />
* liboggz: [http://svn.annodex.net/liboggz/ liboggz svn] or [http://annodex.net/software/liboggz/ liboggz]<br />
* libcmml: [http://svn.annodex.net/libcmml/ libcmml svn] or [http://annodex.net/software/libcmml/ libcmml]<br />
* libannodex: [http://svn.annodex.net/libannodex/ libannodex svn] or [http://annodex.net/software/libannodex/ libannodex]<br />
* the Annodex technology: [http://www.annodex.net/ annodex.net] including perl, python, php bindings, a firefox plugin, authoring software etc.<br />
<br />
<br />
== External links ==<br />
<br />
* CMML is described in more detail in the CMML v2.1 specification: [http://svn.annodex.net/standards/ I-D in svn] or [http://annodex.net/specifications.html I-D]<br />
* [http://www.shindiristudio.com/ Web Design]<br />
<br />
[[Category:Ogg Mappings]]</div>WikiAdminhttps://wiki.xiph.org/index.php?title=XSPF&diff=12868XSPF2011-07-03T15:01:44Z<p>WikiAdmin: </p>
<hr />
<div>'''XML Shareable Playlist Format''' ('''XSPF'''), pronounced "spiff", is a next-generation [http://en.wikipedia.org/wiki/playlist playlist] format for digital media such as songs in Vorbis or MP3 format. This wiki is for developers.<br />
<br />
The mime type for XSPF playlists is <tt>application/xspf+xml</tt>.<br />
<br />
Spec is at http://www.xspf.org/specs/<br />
<br />
== Supporting applications ==<br />
<br />
These are applications which support XSPF and have not yet been added to the [[http://xspf.org/applications][main applications list]].<br />
<br />
* [http://www.jamendo.com/ Jamendo]<br />
** You have to be a member and to select "XSPF" in your preferences to use them by default, but you can look and test a sample playlist here: http://www.jamendo.com/get/track/id/album/audio/xspf/1003/?aue=ogg2<br />
* http://www.ArtistServer.com<br />
** on artist profile pages http://www.artistserver.com/bliss<br />
** on stations and playlists http://www.artistserver.com/stations/<br />
** on genre pages http://www.artistserver.com/DownTempo<br />
* Project Opus http://projectopus.com<br />
** see http://www.projectopus.com/new-player for details<br />
** includes modified version of Fabricio's player<br />
<br />
"We added: A Scrubber/Shuttle so the lister can move the playhead to any point along the song. Time Remaining, Elapsed Time Played, Genre of Song, Origin/Location (city) of artist. Site specific stuff which my not be of interest to others is: Review song link: we were adding as a layer to the player but, it got too large and ugly. Buy song link. And a bunch of nice styling/skin tweaks."<br />
<br />
* trend of XSLT for xspf to html example<br />
** http://dokerlund.edhsweb.org/wordpress/archives/23 is announce<br />
** http://dokerlund.edhsweb.org/wordpress/xspf/media/playlist.xml is in practice<br />
* Zuardi player modified to support FLV and SWF as well as mp3: http://blitz-xplore.blogspot.com/2006/05/file-xspfplayer.html<br />
<br />
== Limited supporting applications ==<br />
* foo_xspf - writes xspf files only with location. So the goal of playlist sharing between friends is not achieved.<br />
* [http://roaraudio.keep-cool.org/rpld.html RoarAudio PlayList Daemon] - no read support yet.<br />
<br />
== Non supporting applications listed as supporting ==<br />
* http://php4xspf.berlios.de/ - From their page: Note: The classes are stil in alpha and do not incorporate ... even the possibility to parse a XSPF file.<br />
<br />
== See also ==<br />
<br />
* [[XSPF FAQ]]<br />
* [[XSPF v1 Notes and Errata]]<br />
* '''[[XSPF Year 2009]]'''<br />
* [[XSPF Conformance Tests]]<br />
* [[XSPF Wish List]]<br />
* [[XSPF Examples in the wild]]<br />
* [[List of known XSPF extensions]]<br />
* [[List of known XSPF metas]]<br />
* [[JSPF Draft|JSPF]] (''JSON Sharable Playlist Format'' a.k.a. ''XSPF on JSON'')<br />
<br />
== External links ==<br />
<br />
* [http://xspf.org/xspf-v1.html XSPF specification]<br />
* [http://validator.xspf.org/ Online XSPF Validator]<br />
* [https://trac.xiph.org/browser/websites/xspf.org/images/banners "Valid XSPF" button]<br />
* [https://trac.xiph.org/browser/trunk/xspf/ Source control for source code, spec, XSLT, validation]<br />
* [https://trac.xiph.org/browser/websites/xspf.org/ Source control for XSPF.org website]<br />
* [http://downloads.xiph.org/releases/xspf/ XSPF-related releases]<br />
* [http://gonze.com/playlists/playlist-format-survey.html A survey of playlist formats], by Lucas Gonze<br />
* [http://en.wikipedia.org/wiki/XSPF XSPF Reference page on Wikipedia]<br />
* [http://web.archive.org/web/20060410160006/http://playlist.musicbrainz.org/playlist/moin.cgi/ Old XSPF wiki]<br />
* [http://www.shindiristudio.com/SEO-optimizacija-sajta/ Optimizacija]<br />
* [http://www.shindiristudio.com/ Web Design Studio]<br />
<br />
[[Category:XSPF]]</div>WikiAdminhttps://wiki.xiph.org/index.php?title=XiphWiki:Sandbox&diff=12867XiphWiki:Sandbox2011-07-03T14:57:39Z<p>WikiAdmin: </p>
<hr />
<div>= Headline 1 =<br />
foo<br />
== Headline 2 ==<br />
=== Headline 3 ===<br />
=== Headline 4 ===<br />
{| border=2 cellpadding=10<br />
|+ '''Table test'''<br />
| x || 'One' || ''Two2'' || '''Three'''<br />
|-<br />
! what is this<br />
| 'yes' <br />
| ''no'' <br />
! maybe<br />
FooBar<br />
|-<br />
!<br />
{| border=1 cellpadding =2<br />
|+ for you<br />
| a<br />
| b<br />
| c<br />
|-<br />
| d || e|| f<br />
|}<br />
| 1 || 2 || 3<br />
|}<br />
<br />
This is a good test<br />
<br />
== Headline 5 ==<br />
<br />
* Item 1<br />
* Item 2<br />
* Item 3<br />
<br />
<br />
LoSSSSSSSSSSSSSSSSSSSSSSSSSSSSSStus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.<br />
<br />
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<br />
<br />
Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.<br />
<br />
== Headline 2 ==<br />
Good goodess, don't you hate wiki spam?<br />
<br />
External link: [[http://google.com This is an external link]]<br />
<br />
Link to PortablePlayers page:[[PortablePlayers]]<br />
<br />
Using different value for the link text: [[PortablePlayers|link to page PortablePlayers]]<br />
<br />
Link to [[DummyApps]] sandbox<br />
<br />
* [http://www.shindiristudio.com/ Web dizajn studio]<br />
<br />
== Headline 3 ==<br />
It seems that [[Talk:Sandbox]] is the canonical way to link to [[Talk:Sandbox|Talk]].<br />
<br />
Fun with tables and templates.<br />
{{PlayersTableHeader|ManufacturerLink=iAudio}}<br />
{{PlayersTableBody|Model=G3|MemType=Flash (builtin)<br />
|MemSize=256MB, 512MB, 1GB<br />
|UMS=Yes<br />
|NeedUpd=NA<br />
|Power=AA battery<br />
|LineIn=Yes<br />
|Mic=Yes<br />
|Radio=Yes<br />
|Formats= MP3, MP2, Ogg, WMA, ASF and WAV<br />
|Comments= Very white, available from online retailers in UK<br />
}}<br />
{{PlayersTableFooter}}<br />
<br />
== Subpages? ==<br />
[[Sandbox/Subpage]]</div>WikiAdminhttps://wiki.xiph.org/index.php?title=Icecast_Server&diff=12866Icecast Server2011-07-03T14:48:58Z<p>WikiAdmin: </p>
<hr />
<div>'''Icecast''' is an open source multi-platform streaming server. It supports [[Ogg]] [[Vorbis]], Ogg [[Theora]], and [[MP3]].<br />
<br />
== External links ==<br />
<br />
* [http://www.icecast.org/ Icecast homepage]<br />
* [http://dir.xiph.org/index.php Stream directory]<br />
* [http://www.OutdoorFountains.com Outdoor Fountains]- To find out and learn helpful tips in our outdoor living learning center.<br />
* [http://www.shindiristudio.com/ Web Design]- To find out and learn helpful tips about web design.<br />
* [http://www.nabble.com/Icecast-f2880.html Icecast archive / forum] - an Icecast mailing list archive that combines both user and dev lists. It is hosted by [http://www.nabble.com/ Nabble]. You can search or browse Icecast discussions here.<br />
<br />
== Development ==<br />
<br />
*trunk http://svn.xiph.org/icecast/trunk/icecast<br />
*kh-branch http://svn.xiph.org/icecast/branches/kh/icecast<br />
**diff to trunk<br />
***fast pre-buffering aka burst-on-connect. <br>State a burst size in bytes to indicate how much should be sent at listener connect.<br />
***mp3 accepts artist and title separately on the url.<br />
***program invocation at stream start and end, per mount based.<br />
***on-demand relays, activated on first listener, disconnected when listenersfalls to 0. <br>Available for master relays as well.<br />
***multiple Ogg codec streaming. Current codecs handled are Theora, Vorbis, Speex, Writ.<br />
***Clients are started at theora key frame if theora is being streamed.<br />
***Added URL and command based listener authentication<br />
***server xml reload, and reopen logging available via admin url<br />
***slave startup re-organised so that relays are more independant<br />
***on xml reload, active sources are updated as well<br />
***When max-listeners reached, a HTTP 302 code can be sent to redirect clients to alternative slave hosts.<br />
***authenticated relays, those that match the relay user/pass, bypass the max-listener check<br />
<br />
== Wish List ==<br />
<br />
As good ideas are never a waste, and for tracking purposes, please list here all the features you're missing in icecast trunk.<br />
<br />
Note: please check that the feature you request is not already in trunk before posting !<br />
<br />
* Ponnies<br />
<br />
[[Category:Xiph-related Software]]</div>WikiAdmin