<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.xiph.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=DavidSchleef</id>
	<title>XiphWiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.xiph.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=DavidSchleef"/>
	<link rel="alternate" type="text/html" href="https://wiki.xiph.org/Special:Contributions/DavidSchleef"/>
	<updated>2026-05-01T12:43:03Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.45.1</generator>
	<entry>
		<id>https://wiki.xiph.org/index.php?title=OggCELT&amp;diff=10527</id>
		<title>OggCELT</title>
		<link rel="alternate" type="text/html" href="https://wiki.xiph.org/index.php?title=OggCELT&amp;diff=10527"/>
		<updated>2009-08-29T23:21:05Z</updated>

		<summary type="html">&lt;p&gt;DavidSchleef: /* Ogg mapping (experimental) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;__NOTOC__&lt;br /&gt;
{{draft}}&lt;br /&gt;
&lt;br /&gt;
CELT is an experimental audio codec for use in low-delay communication.&lt;br /&gt;
&lt;br /&gt;
The name stands for &amp;quot;Code-Excited Lapped Transform&amp;quot;. It applies some of the [[Wikipedia:CELP|CELP]] principles, but does everything in the frequency domain, which removes some of the limitations of CELP. &lt;br /&gt;
&lt;br /&gt;
The CELT codec is meant to close the gap between [[Vorbis]] and [[Speex]] for applications where both high quality audio and low delay are desired.  It is a&lt;br /&gt;
&lt;br /&gt;
Current features include:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Ultra-low latency (typically from 3 to 9 ms)&#039;&#039;&#039;&lt;br /&gt;
* Full audio bandwidth (44.1 kHz and 48 kHz)&lt;br /&gt;
* Stereo support&lt;br /&gt;
* Packet loss concealment&lt;br /&gt;
* Constant bit-rates from 32 kbps to 128 kbps and above&lt;br /&gt;
* A fixed-point version of the encoder and decoder&lt;br /&gt;
&lt;br /&gt;
The [http://www.celt-codec.org/ CELT homepage] has all additional info as well as samples.&lt;br /&gt;
&lt;br /&gt;
==CELT Tuning==&lt;br /&gt;
&lt;br /&gt;
CELT currently provides three classes of tuning knobs.&lt;br /&gt;
&lt;br /&gt;
===Bit allocation for the spectrum details===&lt;br /&gt;
The frequency-dependent allocation of bits used to represent the &#039;details&#039; of each frame&#039;s spectrum is by far the most important set of tuneables in CELT. &lt;br /&gt;
&lt;br /&gt;
There is a matrix in modes.c called &amp;quot;band_allocation&amp;quot;. It has BITALLOC_SIZE lines and BARK_BANDS columns. Each line determines how many bits will be allocated to each critical band. &lt;br /&gt;
&lt;br /&gt;
Even in CBR mode (the only mode currently supported) the available number of bits will change from frame to frame because the space consumed by the compressed spectral envelope is not constant. However, at a single constant bitrate the available number of bits does not change tremendously much from frame to frame, as a result most of the values in the matrix will have little to no effect at any particular bit-rate setting.&lt;br /&gt;
&lt;br /&gt;
The particular bit-rate that a line is used for is not explicitly specified but is instead inferred by the actual bit consumption of that line.&lt;br /&gt;
&lt;br /&gt;
When the amount of bits available is somewhere between the amounts provided by explicitly configured lines the encoder will interpolate between the two nearest matching lines to achieve the needed bit-rate.&lt;br /&gt;
&lt;br /&gt;
===Minimum width of bands===&lt;br /&gt;
At low frequencies critical bands are too narrow to be useful so CELT imposes a minimum width for the bands. &lt;br /&gt;
&lt;br /&gt;
The minimum width is defined in MDCT frequency bins and is controlled by MIN_BINS in modes.c. &lt;br /&gt;
&lt;br /&gt;
If MIN_BINS is set to a small value there will be more bands and as a result more energy data to encode which hurts the encoder&#039;s efficiency. If MIN_BINS is set to a large value there may not be enough frequency-resolution to encode the spectral shape in a manner which conforms well to human perception.&lt;br /&gt;
&lt;br /&gt;
===Band energy resolution===&lt;br /&gt;
&lt;br /&gt;
The last set of parameters is the resolution of the quantizer used to encode the &#039;shape&#039; of the spectrum of every frame.  Ideally the shape of the spectrum would be encoded as as accurately as possible, but every bit used to accurately represent the shape of the spectrum is unavailable to represent the spectrum details. The sensitivity of the human perceptual system to the exact amount of energy in a critical band is limited, especially at higher frequencies. &lt;br /&gt;
&lt;br /&gt;
The resolution is defined in the &amp;quot;frac&amp;quot; array in quant_bands.c. The values themselves are the number of subdivisions to use in 6 dB, i.e. for band i, the resolution used is 6/frac[i] dB. So the higher the value, the more accurate the encoding and the more bits it takes.&lt;br /&gt;
&lt;br /&gt;
== Design decisions ==&lt;br /&gt;
&lt;br /&gt;
* How do we allocate the fine energy bits?&lt;br /&gt;
* Do we have a fixed static bit allocation or do we transmit it in a header?&lt;br /&gt;
* Dynamic bit allocation?&lt;br /&gt;
&lt;br /&gt;
== Ogg mapping (experimental) ==&lt;br /&gt;
&lt;br /&gt;
Default field type: LITTLE ENDIAN unsigned integer&lt;br /&gt;
&lt;br /&gt;
   0                   1                   2                   3&lt;br /&gt;
   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&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | codec_id: Identifier char[8]: &#039;CELT    &#039;                      | 0-3&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  |                                                               | 4-7&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | codec_version: char[20]                                       | 8-11&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  |                                                               | 12-15&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  |                                                               | 16-19&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  |                                                               | 20-23&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  |                                                               | 24-27&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | version_id                                                    | 28-31&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | header_size                                                   | 32-35&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | sample_rate                                                   | 36-39&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | nb_channels                                                   | 40-43&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | frame_size                                                    | 44-47&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | overlap                                                       | 48-51&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | bytes_per_packet                                              | 52-55&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
  | extra_headers                                                 | 56-59&lt;br /&gt;
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;br /&gt;
&lt;br /&gt;
[[Category:Ogg Mappings]]&lt;/div&gt;</summary>
		<author><name>DavidSchleef</name></author>
	</entry>
	<entry>
		<id>https://wiki.xiph.org/index.php?title=Summer_of_Code_2008&amp;diff=4838</id>
		<title>Summer of Code 2008</title>
		<link rel="alternate" type="text/html" href="https://wiki.xiph.org/index.php?title=Summer_of_Code_2008&amp;diff=4838"/>
		<updated>2006-04-27T01:54:35Z</updated>

		<summary type="html">&lt;p&gt;DavidSchleef: /* Ogg Dirac mapping and integration in players */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== DRAFT ==&lt;br /&gt;
&lt;br /&gt;
This is a draft proposal for Google Summer of Code projects with Xiph.org.&lt;br /&gt;
&lt;br /&gt;
We need a primary and backup mentor volunteer for any project that is to become an official proposal.&lt;br /&gt;
&lt;br /&gt;
=== Optimize Theora encoding/decoding speed, SSE/SSE2 ===&lt;br /&gt;
Work on MMX, SSE/SSE2 implementations of the crucial encoding and&lt;br /&gt;
decoding  elements in libtheora. This could continue in theora-exp&lt;br /&gt;
where with ruik&#039;s work or consolidate theora-mmx, theora-oil work into&lt;br /&gt;
trunk. The results must still build cleanly on other archs and do &lt;br /&gt;
run-time capability detection.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Mentor: Ralph Giles, backup: Jan Gerber, Mike Smith&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Theora reference encoder quality optimization ===&lt;br /&gt;
The libtheora encoder could make more use of some features present in the spec&lt;br /&gt;
but not currently implemented in the encoder. This is a little open ended, but&lt;br /&gt;
suggestions are: quant matrix tuning, per-block qi choice, 4:2:2 and 4:4:4 chroma&lt;br /&gt;
support.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Mentor: Ralph Giles, backup: Timothy Terriberry&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Encode support in theora-exp ===&lt;br /&gt;
Implement a rate-distortion optimized encoding mode for theora-exp,&lt;br /&gt;
including R-D optimzed mode decision and quantization (e.g., constant&lt;br /&gt;
lambda). Then, use the above routines to implement a medium-latency ABR&lt;br /&gt;
encoding mode (e.g., varying lambda), with a default target buffer size&lt;br /&gt;
of approximately 2 seconds.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Mentor: Timothy &amp;quot;Derf&amp;quot; Terriberry, backup: Mike Smith, Ralph Giles&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Development assistant for the &amp;quot;Ghost&amp;quot; audio codec ===&lt;br /&gt;
Designing a cutting edge perceptual codec is a very daunting task. Xiph&lt;br /&gt;
is in the research stage on a new low-latency, general purpose audio codec,&lt;br /&gt;
code-named &amp;quot;Ghost&amp;quot;. This is basically a &amp;quot;code assistant&amp;quot; position, where you&lt;br /&gt;
will be asked to implement, test, and give feedback on ideas from Christopher&lt;br /&gt;
Montgomery, designer of the Ogg Vorbis format. Be prepared to learn a lot about&lt;br /&gt;
audio coding, or apply what you already know. While there&#039;s less &amp;quot;ownership&amp;quot;&lt;br /&gt;
potential in this project proposal, it will be a great opportunity to learn&lt;br /&gt;
about compression algorithm design, practice your programming chops, and learn&lt;br /&gt;
to work in team.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Mentor: Christopher &amp;quot;Monty&amp;quot; Montgomery, backup: Jean-Marc Valin&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== OggMNG implementation ===&lt;br /&gt;
Implement the OggMNG decode support in gstreamer and/or illi&#039;s dshow filters.&lt;br /&gt;
Implement encoding support in based on byzanz or istambul. Bonus points for&lt;br /&gt;
overlay support.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Mentors: Mike Smith, Ralph Giles&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Subtitle Editor ===&lt;br /&gt;
this project would also consolidate the various proposals for&lt;br /&gt;
subtitles. from what i saw on #annodex,&lt;br /&gt;
using CMML might be the way to go. Coordinate with Annodex.net.&lt;br /&gt;
&lt;br /&gt;
another option is to pick an existing format (e.g. srt) and get a&lt;br /&gt;
gui mockup done. It should: give you playback with scrubbing, let&lt;br /&gt;
you set in and out points, and write out the results in an Ogg File.&lt;br /&gt;
&lt;br /&gt;
=== OggSkeleton tool support ===&lt;br /&gt;
Implement OggSkeleton production in various xiph tool packages. Also&lt;br /&gt;
implement some playback support at least one popular playback framework:&lt;br /&gt;
illi&#039;s dshow filters, gstreamer/totem, VLC, Quicktime, etc.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Mentor: Conrad Parker, backup: Silvia Pfeiffer&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== MXF support in gstreamer ===&lt;br /&gt;
Implement an MXF mux/demux for gstreamer, with mappings for Vorbis and Theora.&lt;br /&gt;
This should probably be a gstreamer project instead.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Mentors: Christian Schaller, Mike Smith&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
=== Hardware implementation of Theora decoding ===&lt;br /&gt;
Working on a hardware theora decoder, that can be used in embedded&lt;br /&gt;
devices, dvd players and video pods. Presumedly GPL verilog source&lt;br /&gt;
to run on an FPGA.&lt;br /&gt;
&lt;br /&gt;
=== Ogg Dirac mapping and integration in players ===&lt;br /&gt;
this could be a) writing down the spec for ogg dirac that is floating&lt;br /&gt;
around on the dirac and carid mailing list and&lt;br /&gt;
implementing it in i.e. vlc or gstreamer.&lt;br /&gt;
&lt;br /&gt;
j^ note: in whats state is ogg dirac right now anyway?&lt;br /&gt;
&lt;br /&gt;
rillian note: OggDirac is pretty much waiting on schoedinger and a spec revision from Tim at the BBC. I&#039;m not sure this would make a good project, but maybe ds would like help with something.&lt;br /&gt;
&lt;br /&gt;
ds note: probably not a good project for working on the OggDirac definition itself, but implementing it in all the players/encoders out there could be.&lt;br /&gt;
&lt;br /&gt;
=== Intel to AT&amp;amp;T x86 assembly translation ===&lt;br /&gt;
There is a general need for cross platform projects to be able to compile the same asm accelleration code on both GCC and MSVC. Unfortunately, at least of x86, they have incompatible assembly formats. Currently people either convert one to the other by hand (a maintenance nightmare) or require an external compile/assemble step on one or the other platform.&lt;br /&gt;
&lt;br /&gt;
Start with the (unmaintained?) intel2gas script. Spruce it up to support all of recent MMX, SSE, SSE2, SSE3 instructions. Then implement the reverse translation. Once both are working, write some glue code so it can be easily used as part of a GNU autotools build to derive one set of source from the other at build or package time.&lt;/div&gt;</summary>
		<author><name>DavidSchleef</name></author>
	</entry>
</feed>