XiphWiki - User contributions [en]

OpusFAQ

2026-01-04T13:32:52Z

Rillian: /* How do I report a bug? */

[[Image:Opus logo trans.png]]

If you are looking for info not covered in this FAQ, try the '''[https://opus-codec.org main Opus website]''' or the pages included in the '''[[:Category:Opus|Opus category]]''' of this wiki.

== General Questions ==

=== What is Opus? Who created it? ===

Opus is a totally open, royalty-free, highly versatile audio codec.

It is primarily designed for interactive speech and music transmission over the Internet, but is also applicable to storage and streaming applications. It incorporates technology from Skype's '''[https://en.wikipedia.org/wiki/SILK SILK]''' codec and Xiph.Org's '''[http://celt-codec.org/ CELT]''' codec. It has been standardized by the '''[https://www.ietf.org/ Internet Engineering Task Force]''' (IETF) as '''[https://tools.ietf.org/html/rfc6716 RFC 6716]'''.

Opus has been in development since early 2007. Programmers associated with '''[https://xiph.org/ Xiph.Org]''', '''[https://www.skype.com/ Skype]''' and several other organizations have contributed to its development and to the standardization process as part of the '''[https://datatracker.ietf.org/wg/codec/charter/ IETF's Codec Working Group]'''.

=== How does Opus compare to other codecs? ===

Opus is distinguished from most high quality formats (eg: [[Vorbis]], AAC, MP3) by having '''[https://tools.ietf.org/html/rfc6716#section-2 low delay]''' (5 ~ 66.5 ms) and distinguished from most low delay formats (eg: [[Speex]], G.711, GSM) by supporting '''[https://tools.ietf.org/html/rfc6716#section-2.1.1 high audio quality]''' (supports narrow-band all the way to full-band audio).

It '''[https://opus-codec.org/comparison meets or exceeds existing codecs' quality]''' across a wide range of bitrates, and it operates at lower delay than virtually any existing compressed format.

Most importantly, the Opus format and its reference implementation are both available under '''[https://opus-codec.org/license/ liberal, royalty-free licenses]'''. 
This makes it:
* easy to adopt
* compatible with free software
* suitable for use as part of the basic infrastructure of the Internet

=== Does Opus make all those other lossy codecs obsolete? ===

Yes.

From a technical point of view (loss, delay, bitrates, ...) Opus renders '''[[Speex]]''' obsolete and should also replace '''[[Vorbis]]''' and the common proprietary codecs too (e.g. AAC, MP3, ...).

=== Will Opus replace Vorbis in video files? ===

For '''[[Ogg]]''' video files (which use the '''[[Theora]]''' video codec), you ''can'' use Opus instead of Vorbis, but the overall size reduction will be minimal and it will break compatibility with existing players.

For WebM video files, the convention is to use the '''[http://www.webmproject.org/vp9/ VP9 video codec]''' when using Opus as an audio codec.

=== How do I use Opus? ===

For now, the best way to '''encode''' audio into Opus files is to use the '''opusenc''' command-line tool from the '''[https://opus-codec.org/downloads/ opus-tools package]'''.

If you want to encode many files at once (e.g. your music library), try the applications listed in the '''[[OpusSupport|Opus Support]]''' page.

For rough guidelines on encoding settings, see the '''[[Opus Recommended Settings]]''' page.

=== What programs support Opus? ===

Opus decoding support is now included in '''[http://caniuse.com/opus some Internet browsers]''' and '''[[OpusSupport|many applications]]''', including '''[https://www.mozilla.org/firefox Firefox]''', '''[https://www.foobar2000.org/ foobar2000]''' and '''[https://www.videolan.org/vlc/ VLC]''', as well as in frameworks such as '''[https://gstreamer.freedesktop.org/ GStreamer]''' and '''[https://ffmpeg.org/ FFmpeg]'''.

For real-time applications, Opus support is available in '''[https://www.webrtc.org/ Google's WebRTC codebase]'''.

Opus is a relatively new codec (standardized in September 2012), but '''[[OpusSupport|many more applications]]''' will support it in the near future.

=== Does Opus support higher sampling rates, such as 96 kHz or 192 kHz? ===

Yes and no.

Opus encoding tools like opusenc will happily encode input files that are sampled at 96 or 192 kHz.

However, files at these rates are internally '''converted to 48 kHz''' and then only frequencies '''up to 20 kHz''' are encoded.

The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.

See Monty's '''[https://web.archive.org/web/20200426050432/https://people.xiph.org/~xiphmont/demo/neil-young.html article]''' for more details.

If you want a codec to handle high sampling rates losslessly, use '''[[FLAC]]'''!

=== What are the licensing requirements? ===

The reference Opus source code is released under a three-clause BSD license, which is a very permissive Open Source license. Commercial use and distribution (including in proprietary software) is permitted, provided that some basic conditions specified in the license are met.

Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with (hopefully) all open source licenses, including the GPL (v2 and v3).

See the '''[https://www.opus-codec.org/license/ Opus Licensing]''' page for details.

=== Why make Opus free? ===

On the Internet, protocol and codec standards are part of the common infrastructure everyone builds upon.

Most of the value of a high-quality standard is the innovation and inter-operation provided by the systems built on top of it. When a few parties have monopoly rights to monetize a standard, that infrastructure stops being so common and everyone else has more reason to use their own solution instead, increasing cost and reducing efficiency.

Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected.

This is why Opus, unlike many codecs, is free.

=== Is the SILK part of Opus compatible with the SILK implementation shipped in Skype? ===

No.

The SILK codec, as submitted by Skype to the IETF, was heavily modified as part of its integration within Opus. The modifications are significant enough that it is not possible to just write a "translator". Even sharing code between Opus and the "old SILK" would be highly complex.

=== Why not keep the SILK and CELT codecs separate? ===
Opus is more than just two independent codecs with a switch.

In addition to a [https://en.wikipedia.org/wiki/Linear_predictive_coding Linear Prediction] '''SILK mode''' and an [https://en.wikipedia.org/wiki/Modified_discrete_cosine_transform MDCT] '''CELT mode''' it has a '''hybrid mode''', where speech frequencies up to 8 kHz are encoded with LP while those between 8 and 20 kHz are encoded with MDCT. This is what allows Opus to have such high speech quality around 32 kbps.

Another advantage of the integration is the ability to switch between these 3 modes seamlessly, without any audible "glitches" and without any out-of-band signalling.

=== Now that Opus is standardized, will its development stop or can it be further improved? ===
Yes, Opus '''can''' and '''should''' be improved, because unlike most '''[https://en.wikipedia.org/wiki/ITU-T#Key_standards_published_by_ITU ITU-T codecs]''', Opus is only defined in terms of its decoder.

The encoder can keep evolving as long as the bitstream it produces can be decoded by the reference decoder. This is what made it possible for modern MP3 encoders (e.g. '''[https://en.wikipedia.org/wiki/LAME LAME]''') to improve far beyond the original '''[https://en.wikipedia.org/wiki/L3enc L3enc]''' and '''dist10''' reference implementations.

Although it is unlikely that Opus encoders will see such a spectacular evolution, we certainly hope that future encoders will become much better than the reference encoder.

In fact, the 1.1 libopus release significantly improves on the reference encoder's quality. See '''[https://web.archive.org/web/20190814051043/https://people.xiph.org/~xiphmont/demo/opus/demo3.shtml Monty's demo]''' for more details.

=== Will all future Opus releases comply with the [https://tools.ietf.org/html/rfc6716 Opus specification]? ===

Yes.

=== In what ways is Opus optimized for the Internet? ===

Opus has good packet loss robustness and concealment, but its optimisations go further.

One of the first things we've been asked when designing Opus was to make the rate '''really''' adaptable because we never know what kind of rates will be available. This not only meant having a wide range of bitrates, but also being able to vary in small increments.

This is why Opus scales from about '''6 ''' to '''512 kb/s''', in increments of '''0.4 kb/s''' (one byte with 20 ms frames). Opus can have '''more than 1200 possible bitrates''' while spending only '''11 bits''' signalling the bitrate because UDP already encodes the packet size.

One last aspect is that Opus is simple to transport over RTP, as can be seen from the [https://tools.ietf.org/html/rfc7587 Opus RTP payload format]. For example, it's possible to decode RTP packets without having even seen the SDP or any out-of-band signalling.

=== What applications for Android can play Opus? ===

Right now, there are just a few but that list is fast growing. Please reference [https://android.stackexchange.com/q/37970/7425 this question on android.stackexchange.com]. Feel free to suggest other applications.

=== When will the next version be released? ===

When it's done. Seriously, we do not know.

Opus is not a large project with a fixed release schedule.

That being said, our '''[https://www.opus-codec.org/downloads/ pre-releases]''' and even the git repositories ('''[https://gitlab.xiph.org/xiph/opus/-/tree/master Xiph]''', '''[https://github.com/xiph/opus GitHub]''') are pretty stable and given proper testing (which you should always do anyway), are safe to distribute.

Just be aware that the API of new features (that have never been included in a stable release) could potentially still change.

== Software Developers' Questions ==

=== On what platforms does Opus run? ===

The Opus code base is written in C89 and should run on the vast majority of recent (and not so recent) CPUs.

Some of the platforms on which Opus has been tested<ref name="mf4-tests">Automated test results used to be available [https://mf4.xiph.org/jenkins/view/opus/ here] ([https://web.archive.org/web/20160316111354/https://mf4.xiph.org/jenkins/view/opus/ last saved copy]). The [https://gitlab.xiph.org/xiph/opus/-/tree/master new git repository] doesn't have any links to test results, but you can always run the tests yourself!</ref> include x86, x86-64, ARM, Itanium, Blackfin, and SPARC.

=== Is there a fixed-point implementation? ===

Yes.

The fixed-point and floating-point decoder and encoder implementations are part of the same code base.

The code defaults to float, so you need to configure with '''--enable-fixed-point''' (or define '''FIXED_POINT''' if not using the configure script) to build the code for fixed-point.

=== Which implementation should I use? ===

While the implementation in RFC 6716 is what ''defines'' the standard, it is likely not the best and most up-to-date implementation.

The [https://opus-codec.org/ Opus] website was set up for the purpose of continually improving the implementation — in terms of speed, encoding quality, device compatibility, etc — while still conforming to the standard.

All Opus implementations are compatible by definition.

=== How is supporting Opus different from supporting Speex/G.711/MP3? ===

Opus has variable frame durations which can change on the fly, so an Opus decoder needs to be ready to accept packets with durations that are '''any multiple of 2.5ms''' up to a '''maximum of 120ms'''.

The opus encoder and decoder do not need to have matched sampling rates or channel counts. It is recommended to always just decode at the highest rate the hardware supports (e.g. 48kHz stereo) so the user gets the full quality of whatever the far end is sending.

=== My application doesn't work. Can anyone help me? ===

It's possible to get help, but before doing so, there are a few basic things to try:

* Implement your application with uncompressed audio instead of Opus. If it still doesn't work, then the problem isn't related to Opus.
* Read the [https://www.opus-codec.org/docs/ Opus documentation].
* Read the [https://gitlab.xiph.org/xiph/opus/-/blob/master/src/opus_demo.c opus_demo.c] source code to see how to use the encoder and decoder.

If you still can't solve the problem, the best option is to ask for help on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on the '''#opus''' IRC channel on '''irc.freenode.net'''.

=== How do I report a bug? ===

If you think you have found a bug in Opus (and not in your application), please [https://gitlab.xiph.org/xiph/opus/-/issues file an issue].

Please include a way for us to reproduce the problem. The best way to do this is to provide an input file, along with the opusenc/opusdec/opus_demo command line that causes the bug to occur.

If the bug cannot be triggered by the command line tools, please provide a simple patch or C file that can help reproduce it. Please also provide any other relevant information, such as OS, CPU, build options, etc.

Don't hesitate to also contact us on the [http://lists.xiph.org/mailman/listinfo/opus mailing list] or on [irc://irc.libera.chat/opus IRC].

=== What is Opus Custom? ===

Opus Custom is an '''optional''' part of the Opus standard that allows for sampling rates other than 8, 12, 16, 24, or 48 kHz and frame sizes other than multiples of 2.5 ms.

Opus Custom requires additional out-of-band signalling that Opus does not normally require and disables many of Opus' coding modes. Also, because it is an optional part of the specification, using Opus Custom may lead to compatibility problems.

For these reasons, '''its use is discouraged''' outside of very specific applications.

You may want to use Opus Custom for:

* ultra-low-delay applications, where synchronization with the soundcard buffer is important.
* low-power embedded applications, where compatibility with others is not important.

For almost all other types of applications, Opus Custom should not be used.

=== How do I use 44.1 kHz or some other sampling rate not directly supported by Opus? ===

Tools which read or write Opus should inter-operate with other sampling rates by transparently performing sample rate conversion behind the scenes whenever necessary. In particular, software developers should not use Opus Custom for 44.1 kHz support, except in the very specific circumstances outlined above.

Note that it's generally preferable for a decoder to output at 48kHz, even when you know the original input was 44.1kHz. This is not only because you can skip resampling, but also because many cheaper audio interfaces have poor quality output for 44.1kHz.

The '''[https://opus-codec.org/downloads/ opus-tools]''' package source code contains a small, high quality, high performance, BSD licensed '''[https://github.com/xiph/opus-tools/blob/master/src/resample.c resampler]''' which can be used where resampling is required.

=== But won't the resampler hurt the quality? Isn't it better to use 44.1 kHz directly? ===

Not really. The quality degradation caused by any reasonable resampler (SoX, libspeexdsp, libsamplerate, ...) is far less than the distortion caused by the best lossy codec at its highest bitrate. If you can't tolerate the quality degradation caused by a good 44.1 ↔ 48 kHz resampler, then you shouldn't be using a lossy codec in the first place. Similarly, the extra CPU spent in the resampler is small compared to the rest of the codec. Not only that, but many soundcards only support 48 kHz on playback, so players can directly play the output rather than resample it to 48 kHz (e.g. for a 44.1 kHz MP3). So effectively, Opus is only shifting the burden of resampling from the decoder side to the encoder side.

One advantage of supporting only one internal rate is that it makes it possible for Opus to support many features, including efficient speech compression (through SILK) and real-time applications. It also means all the quality tuning effort can be spent on a single configuration, which helps bring even better quality.

=== How is the bitrate setting used in VBR mode? ===

Variable bitrate (VBR) mode allows the bitrate to automatically vary over time based on the audio being encoded, in order to achieve a consistent quality.

The bitrate setting controls the desired quality, on a scale that is calibrated to closely approximate the average bitrate that would be obtained over a large and diverse collection of audio. The actual bitrate of any particular audio stream may be higher or lower than this average.

=== What frame size should I use? ===

A '''20ms''' frame size works well for most applications. Smaller frame sizes may be used to achieve lower latency, but have lower quality at a given bitrate.

Sizes greater than 20 ms increase latency and are generally beneficial only at fairly low bitrates, or when used to reduce external overhead (e.g. by reducing the number of packets that are sent). For file encoding, using a frame size larger than 20 ms will usually result in '''worse''' quality for the same bitrate because it constrains the encoder in the decisions it can make.

=== Forward Error correction (FEC) doesn't appear to do anything! HELP! ===

The in-band FEC feature of Opus helps reduce the harm of packet loss by encoding some information about the prior packet.

In order to make use of in-band FEC the decoder must delay its output by at least one frame so that it can call the decoder with the decode_fec argument on the ''next'' frame in order to reconstruct the missed frame. This works best if it's integrated with a jitter buffer.

FEC is only used by the encoder under certain conditions:
* the feature must be enabled via the '''OPUS_SET_INBAND_FEC''' CTL
* the encoder must be told to expect loss via the '''OPUS_SET_PACKET_LOSS_PERC''' CTL
* the codec must be operated in any of the '''Linear Prediction''' or '''Hybrid''' modes

Frame durations shorter than 10ms and very high bitrates will use the MDCT modes, where FEC is not available.

Even when FEC is not used, telling the encoder about the expected level of loss will help it make more intelligent decisions. By default, the implementation assumes there is no loss.

=== I can't use malloc or much stack on my embedded platform. How do I make Opus work? ===

A normal build of libopus only uses <tt>malloc/free</tt> in the <tt>_create()</tt> and <tt>_destroy()</tt> calls, making it safe for realtime use as long as the codec state is pre-created.

To build Opus without the references to <tt>malloc/free</tt>, you must:

* use <tt>init()</tt> calls rather than <tt>create()</tt> calls in your application
* compile with <tt>CFLAGS="-DOVERRIDE_OPUS_ALLOC -DOVERRIDE_OPUS_FREE -D'opus_alloc(x)=NULL' -D'opus_free(x)=NULL' "</tt>.

If libopus is built with <tt>-DNONTHREADSAFE_PSEUDOSTACK</tt> (instead of <tt>VAR_ARRAYS</tt>, or <tt>USE_ALLOCA</tt>), it will use a user-provided block of heap instead of stack for many things, resulting in much lower stack usage. 
This makes the resulting library '''non-threadsafe''' and is '''not recommended''' on anything except limited embedded platforms.

=== How can I ensure that my software interoperates with other software implementing Opus? ===

For applications using Ogg files, there are some [https://web.archive.org/web/20191223064407/https://people.xiph.org/~greg/opus_testvectors/ Ogg Opus testvectors] to test decoders and you can test encoders with opusdec. For RTP applications, the opusrtp tool can be useful.

In general, here's a list of specific issues to check:
* Can your application handle all frame sizes, including changing the frame size from frame to frame?
* Does your application react properly to lost packets, by calling the decoder with a NULL packet?

=== What is the complexity of Opus? ===

The complexity of Opus varies by a large amount based on the settings used.

It depends on the mode, audio bandwidth, number of channels, and even a "complexity knob" that can trade complexity for quality. It will run easily on any recent PC or smartphone.

For slower embedded CPUs/DSPs, the amount of CPU required will vary depending on the configuration and the exact CPU, so you will need to experiment. Do not expect Opus to run quickly on really slow devices like 8-bit micro-controllers.

=== Opus is using too much CPU for my application. What can I do? ===

First don't panic and don't start writing assembly just yet.

It's possible that you're just not using the right set of options.

If you're targeting an embedded/mobile platform, chances are the fixed-point build will be faster, so make sure you're using '''--enable-fixed-point''' or defining '''FIXED_POINT''' in the build system.

Opus also has a complexity option that can trade quality for complexity. The default is highest quality and highest complexity. You can control this using '''OPUS_SET_COMPLEXITY()''' (see the '''[https://www.opus-codec.org/docs/ Documentation]''' for details).

If all else fails and you need to optimize the Opus code, see the next question.

=== I would like to optimize/improve/help with Opus. Where should I start? ===

Please '''[https://www.opus-codec.org/contact/ contact us]''' before you start, or at least before you get too far.

This will help coordinate the efforts made on Opus and reduce the probability of wasting your time on duplicated effort or going down the wrong path. More details in the '''[[OpusContributing|contributing page]]'''.

=== Does Opus have an echo canceller like Speex does? ===

Echo cancellation is completely independent from codecs.

You can use any echo canceller (including the one from libspeexdsp) along with Opus.

That being said, among the free acoustic echo cancelers (AEC) we're aware of, the best is probably the Google AEC from the [https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_processing/ WebRTC codebase].

=== How do I get the duration of a .opus file? ===

Use '''[https://mf4.xiph.org/jenkins/view/opus/job/opusfile-autotools/ws/doc/html/group__stream__info.html op_pcm_total()]''' from '''[https://opus-codec.org/downloads/ libopusfile]'''.

If you want to implement this yourself, you need to
* Read the BOS (Beginning Of Stream) pages to enumerate the serial numbers of all concurrently multiplexed streams, identify the Opus stream you want, and get its preskip value.
* Read up through the first complete audio data page to compute the starting granule position (since the timestamps might not start at 0, e.g., if the file was captured from a live stream that was joined after the start).
* Seek near the end of a file and look for a page with the same serial number as found in the headers (just under 64 kB from the end should be sufficient to ensure you find a page, assuming the Opus data is not multiplexed with another stream and there is no trailing garbage in the file).
* If you find a page whose serial number was not included in the original set of BOS pages, you have a chained stream. You need to bisect the file to identify the end of the first chain and the start of the next, and repeat this process for each link in the chain.
* If you don't find any pages at all, or find a page whose serial number was included in the original set of BOS pages, but was not the serial number of the Opus stream you want, back up and try again (being careful to avoid rescanning the same data, which can produce quadratic worst-case complexity).
* If you find a page whose serial number matches the Opus stream you want, look at its final granule position, and compute the total duration (in seconds) as (final_granule_position - initial_granule_position - preskip)/48000.0.

=== Why don't you store the duration in the header? Isn't all of that slow and complicated? ===

Computing the duration directly from the file contents allows files to be written in a single pass, without any seeking, which is necessary for live streaming. Chaining also simplifies live streaming, as you can just pipe multiple files into the same network connection, with all associated metadata updates, etc., and the results are still valid .opus files (contrast with the '''[http://www.smackfu.com/stuff/programming/shoutcast.html hacks used to add metadata to MP3 streams]''').

Opening a typical .opus file, which is not multiplexed and not chained, and computing the duration over the network requires just one extra HTTP request, which can proceed in parallel with the buffering in the main request. This is the behavior you will get from libopusfile's HTTP backend by default.

Enumeration of chain boundaries can be expensive in files with many links, but in our testing libopusfile used nearly an order of magnitude fewer seeks to do this than some other media frameworks (at the time). Storing a duration in a header wouldn't solve this, since every link in a chain has its own, independent headers. If the cost of chain enumeration is a problem, the best way to avoid it is to store the links in separate files (i.e., don't use chaining).

=== How do I seek in a .opus file? ===

Use '''[https://mf4.xiph.org/jenkins/view/opus/job/opusfile-autotools/ws/doc/html/group__stream__seeking.html op_pcm_seek() or op_raw_seek()]''' from '''[https://opus-codec.org/downloads/ libopusfile]'''.

If you want to implement seeking yourself, you need to
* Identify the link that contains the target (if you have a chained file).
* Adjust the target by 80 ms to get enough pre-roll data (to ensure the decoder will have converged by the time you reach the target), as recommended by '''[https://tools.ietf.org/html/rfc7845 RFC 7845]'''.
* Estimate the location of the last audio data page with a completed packet prior to the adjusted target, using the duration and size (in bytes) of the link.
* Seek to that location and scan forward until you find an audio data page with a completed packet (that contains a valid granule position).
* If you think you are sufficiently close to the adjusted target, scan forward until you find the next audio data page with a completed packet.
* If the adjusted target lies between the first audio data page with a completed packet you found and the next one, stop. You can decode forward from here and start playing when you reach your (original, unadjusted) target.
* Otherwise, go back and re-estimate the seek location using the granule positions and file offsets of the page(s) you just found.

libopusfile includes fallbacks to prevent pathological worst-case behavior when its guesses are repeatedly wrong. Weighted bisection can degrade to a linear scan, but libopusfile's worst case is within a constant factor of naive bisection (i.e., logarithmic). We have only ever observed such pathological behavior in files we manually constructed to trigger it.

libopusfile also takes shortcuts when the target location is near the current position, to make small seeks cheaper. In the best case it can loop forever over very short files whose data is contained in a single page (e.g., less than 1 second long with default encoder settings) without any seeking at all.

You can find more information on seeking in files that contain Opus multiplexed with other streams (e.g., video) '''[[GranulePosAndSeeking|on this page]]'''.

=== Wouldn't it be better to build an index? ===

As with file durations, an index at the beginning of the file is incompatible with live streaming. It also means more data has to be fetched before a file can start playing over the network, because you must read past the index even when you don't intend to seek. The index could be stored at the end (which even still allows encoding the file in a single pass), but this requires one (or more) extra seeks to read the index (especially if its exact location at the end is not known), either on file open or on first seek. Unlike the final timestamp, which is small and fixed in size, an index grows with the file duration, and can have unbounded size. It is also easy for an index to become out of sync with a file that has been edited or damaged, in which case seeking will simply fail. By contrast, you can seek in a truncated .opus download without issues.

In practice, bisection seeking on VBR audio achieves performance that is very nearly as good as seeking with an index, without any of the drawbacks of an index. libopusfile provides a test program called seeking_example which can be used to benchmark the performance on your files.

On a 96 kbps VBR file nearly one hour long (the second movement of Mahler's Symphony No. 8 "Symphony of a Thousand"):

Testing exact PCM seeking to random places in 169680000 samples (58m55.000s)...
Total seek operations: 1020 (1.020 per exact seek, 2 maximum).

On a chained file formed by concatenating the eight test vectors for the currently supported channel layouts in mapping family 1:

Opened file containing 8 links with 18 seeks (2.250 per link).
Testing exact PCM seeking to random places in 2759064 samples (57.481s)...
Total seek operations: 946 (0.946 per exact seek, 2 maximum).

That is, the number of physical seeks required is almost always 1, every once in a while 2, and in short files, sometimes even 0.

==References==

[[Category:Opus]]

OggPlay

2025-03-01T14:04:08Z

Rillian: /* Overview */ Update overview for current project status and download link

== Overview ==
OggPlay is a library designed to allow drop-in playback of Xiph.Org media in an application. OggPlay handles demuxing and decoding, generates timestamps for raw data, maintains synchronisation across multiple streams, and provides a lock-free buffer implementation for easy multithreading.

An example use of OggPlay library is OggPlay Mozilla Firefox plugin demonstrating how the library can be used to provide Ogg playback in a web browser. OggPlay plugin is implemented through Mozilla NPAPI. The target platforms for the plugin are: Linux/UNIX, Win200x/XP/Vista and MACOSX. The libary as much as the plugin are open source under triple
MPL/GPL/LGPL license. For more details about Mozilla licesing refer to [http://www.mozilla.org/MPL/ Mozilla Code Licensing].

OggPlay was an experimental '''work in progress''' and was eventually replaced within Firefox by a separate native playback implementation.

OggPlay was developed under the [http://www.annodex.net Annodex] project, in co-operation with Xiph.Org. A repository for maintenance is available at https://gitlab.xiph.org/xiph/liboggplay. Source code packages can be found at https://downloads.xiph.org/releases/liboggplay/.

== Developer's Guide ==

=== Linux ===

For instructions how to compile and install Linux version of OggPlay Mozilla plugin refer to [http://wiki.xiph.org/index.php/OggPlay/Linux Linux Developement and Intallation Guide].

=== Windows ===

The Win32 version of the plugin has been developed and tested on Win200x/XP platforms.

For detailed instructions how to setup Mozilla plugin development environment and start hacking on Win32 version of OggPlay Mozilla Firefox plugin go to [http://wiki.xiph.org/index.php/OggPlay/Win32 Win32 Development and Installation Guide.]
 
The same link provides links to the plugin binaries and instructions how to install and test Oggplay Mozilla plugin.

=== MacOS ===

Check out http://svn.annodex.net/liboggplay/trunk/plugin/mac/mac-annodex-dev-install.sh, put it in a working directory somewhere, run the script, and follow the directions.

== Plugin Javascript API ==

View the [[OggPlayJavascriptAPI | draft OggPlay plugin Javascript API]]

[[Category:Xiph-related Software]]

XiphInfra:Overview

2020-05-16T16:20:08Z

Rillian: Add developer category so the page is easier to find.

This Namespace is used to group everything related to Xiph infrastructure. It aims to provide information about the services
in use by Xiph and on which server each of them is hosted.

== List of services ==
Below is a list of all services, if anything is missing, add it to the [[XiphInfra:List of services|List of services page]].
{{XiphInfra:List of services}}

[[Category:Developers stuff]]

XiphInfra:List of services

2020-03-07T16:28:41Z

Rillian: Update maintainer list

{|class="wikitable sortable"
! Service
! URL
! VM
! Host
! Maintainer(s)
|-
| [[AreWeCompressedYet]]
| style="text-align:right;"| https://arewecompressedyet.com
| awcy
| style="text-align:right;"| catfish
| TD-Linux
|-
| Git Repos
| style="text-align:right;"| https://git.xiph.org
|
| style="text-align:right;"| mf4
| ePirat, rillian
|-
| Home Pages
| style="text-align:right;"| https://people.xiph.org
|
| style="text-align:right;"| mf4
|
|-
| [[Icecast]] Streams
| style="text-align:right;"| http://dir.xiph.org
|
| style="text-align:right;"| mf4
| tbr
|-
| [[Icecast]] Streams (Beta)
| style="text-align:right;"| http://dir-test.xiph.org
|
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| Jenkins
| style="text-align:right;"| https://mf4.xiph.org/jenkins/
| jenkins
| style="text-align:right;"| mf4
| TD-Linux
|-
| Mail
| style="text-align:right;"| xiph.org
| mailfish
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| MailMan
| style="text-align:right;"| http://lists.xiph.org
| mailfish
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| Media
| style="text-align:right;"| https://media.xiph.org
|
| style="text-align:right;"| beaufish
| TD-Linux, rillian
|-
| Opus Boodler Streams
| style="text-align:right;"| https://opus-codec.org
|
| style="text-align:right;"| mf4
| gmaxwell
|-
| Rietveld
| style="text-align:right;"| https://review.xiph.org
| jenkins
| style="text-align:right;"| mf4
| TD-Linux
|-
| Social
| style="text-align:right;"| https://social.xiph.org
| social
| style="text-align:right;"| catfish
| tbr
|-
| Subversion Repos
| style="text-align:right;"| https://svn.xiph.org
|
| style="text-align:right;"| mf4
| rillian
|-
| Trac Bug Tracker
| style="text-align:right;"| https://trac.xiph.org
|
| style="text-align:right;"| mf4
| tbr
|-
| [[XiphWiki:Features|Wiki]]
| style="text-align:right;"| https://wiki.xiph.org
| [[XiphInfra:Wiki VM|wiki]]
| style="text-align:right;"| catfish
| ePirat
|-
| Xiph Mirror Repos
| style="text-align:right;"| https://github.com/xiph
|
|
| ePirat, rillian
|-
| XiphBot-ng
| style="text-align:right;"| XiphWiki on freenode.net
|
| style="text-align:right;"| mf4
| TD-Linux
|-
| [[XiphInfra:Gitlab|Gitlab]]
| style="text-align:right;"| https://gitlab.xiph.org
| gitlab
| style="text-align:right;"| catfish
| ePirat, tbr, TD-Linux, rillian
|}

<noinclude>See the [[XiphInfra:Overview|Overview]] page for more information.</noinclude>

XiphInfra:List of services

2020-03-07T16:26:02Z

Rillian: Add social vm, allegedly maintained by tbr

{|class="wikitable sortable"
! Service
! URL
! VM
! Host
! Maintainer(s)
|-
| [[AreWeCompressedYet]]
| style="text-align:right;"| https://arewecompressedyet.com
| awcy
| style="text-align:right;"| catfish
| TD-Linux
|-
| Git Repos
| style="text-align:right;"| https://git.xiph.org
|
| style="text-align:right;"| mf4
| rillian
|-
| Home Pages
| style="text-align:right;"| https://people.xiph.org
|
| style="text-align:right;"| mf4
|
|-
| [[Icecast]] Streams
| style="text-align:right;"| http://dir.xiph.org
|
| style="text-align:right;"| mf4
| tbr
|-
| [[Icecast]] Streams (Beta)
| style="text-align:right;"| http://dir-test.xiph.org
|
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| Jenkins
| style="text-align:right;"| https://mf4.xiph.org/jenkins/
| jenkins
| style="text-align:right;"| mf4
| TD-Linux
|-
| Mail
| style="text-align:right;"| xiph.org
| mailfish
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| MailMan
| style="text-align:right;"| http://lists.xiph.org
| mailfish
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| Media
| style="text-align:right;"| https://media.xiph.org
|
| style="text-align:right;"| beaufish
| TD-Linux
|-
| Opus Boodler Streams
| style="text-align:right;"| https://opus-codec.org
|
| style="text-align:right;"| mf4
| gmaxwell
|-
| Rietveld
| style="text-align:right;"| https://review.xiph.org
| jenkins
| style="text-align:right;"| mf4
| TD-Linux
|-
| Social
| style="text-align:right;"| https://social.xiph.org
| social
| style="text-align:right;"| catfish
| tbr
|-
| Subversion Repos
| style="text-align:right;"| https://svn.xiph.org
|
| style="text-align:right;"| mf4
| rillian
|-
| Trac Bug Tracker
| style="text-align:right;"| https://trac.xiph.org
|
| style="text-align:right;"| mf4
| tbr
|-
| [[XiphWiki:Features|Wiki]]
| style="text-align:right;"| https://wiki.xiph.org
| [[XiphInfra:Wiki VM|wiki]]
| style="text-align:right;"| catfish
| ePirat
|-
| Xiph Mirror Repos
| style="text-align:right;"| https://github.com/xiph
|
|
| rillian
|-
| XiphBot-ng
| style="text-align:right;"| XiphWiki on freenode.net
|
| style="text-align:right;"| mf4
| TD-Linux
|-
| [[XiphInfra:Gitlab|Gitlab]]
| style="text-align:right;"| https://gitlab.xiph.org
| gitlab
| style="text-align:right;"| catfish
| ePirat (VM and Gitlab), tbr (VM and Gitlab), TD-Linux (Gitlab)
|}

<noinclude>See the [[XiphInfra:Overview|Overview]] page for more information.</noinclude>

XiphInfra:List of services

2020-03-07T16:22:42Z

Rillian: hosts don't need to be urls

{|class="wikitable sortable"
! Service
! URL
! VM
! Host
! Maintainer(s)
|-
| [[AreWeCompressedYet]]
| style="text-align:right;"| https://arewecompressedyet.com
| awcy
| style="text-align:right;"| catfish
| TD-Linux
|-
| Git Repos
| style="text-align:right;"| https://git.xiph.org
|
| style="text-align:right;"| mf4
| rillian
|-
| Home Pages
| style="text-align:right;"| https://people.xiph.org
|
| style="text-align:right;"| mf4
|
|-
| [[Icecast]] Streams
| style="text-align:right;"| http://dir.xiph.org
|
| style="text-align:right;"| mf4
| tbr
|-
| [[Icecast]] Streams (Beta)
| style="text-align:right;"| http://dir-test.xiph.org
|
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| Jenkins
| style="text-align:right;"| https://mf4.xiph.org/jenkins/
| jenkins
| style="text-align:right;"| mf4
| TD-Linux
|-
| Mail
| style="text-align:right;"| xiph.org
| mailfish
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| MailMan
| style="text-align:right;"| http://lists.xiph.org
| mailfish
| style="text-align:right;"| catfish
| ePirat, tbr
|-
| Media
| style="text-align:right;"| https://media.xiph.org
|
| style="text-align:right;"| beaufish
| TD-Linux
|-
| Opus Boodler Streams
| style="text-align:right;"| https://opus-codec.org
|
| style="text-align:right;"| mf4
| gmaxwell
|-
| Rietveld
| style="text-align:right;"| https://review.xiph.org
| jenkins
| style="text-align:right;"| mf4
| TD-Linux
|-
| Subversion Repos
| style="text-align:right;"| https://svn.xiph.org
|
| style="text-align:right;"| mf4
| rillian
|-
| Trac Bug Tracker
| style="text-align:right;"| https://trac.xiph.org
|
| style="text-align:right;"| mf4
| tbr
|-
| [[XiphWiki:Features|Wiki]]
| style="text-align:right;"| https://wiki.xiph.org
| [[XiphInfra:Wiki VM|wiki]]
| style="text-align:right;"| catfish
| ePirat
|-
| Xiph Mirror Repos
| style="text-align:right;"| https://github.com/xiph
|
|
| rillian
|-
| XiphBot-ng
| style="text-align:right;"| XiphWiki on freenode.net
|
| style="text-align:right;"| mf4
| TD-Linux
|-
| [[XiphInfra:Gitlab|Gitlab]]
| style="text-align:right;"| https://gitlab.xiph.org
| gitlab
| style="text-align:right;"| catfish
| ePirat (VM and Gitlab), tbr (VM and Gitlab), TD-Linux (Gitlab)
|}

<noinclude>See the [[XiphInfra:Overview|Overview]] page for more information.</noinclude>

XiphInfra:List of services

2020-03-07T16:18:44Z

Rillian: wiki vm is on catfish

{|class="wikitable sortable"
! Service
! URL
! VM
! Host
! Maintainer(s)
|-
| [[AreWeCompressedYet]]
| style="text-align:right;"| https://arewecompressedyet.com
| awcy
| style="text-align:right;"| https://catfish.xiph.org
| TD-Linux
|-
| Git Repos
| style="text-align:right;"| https://git.xiph.org
|
| style="text-align:right;"| https://mf4.xiph.org
| rillian
|-
| Home Pages
| style="text-align:right;"| https://people.xiph.org
|
| style="text-align:right;"| https://mf4.xiph.org
|
|-
| [[Icecast]] Streams
| style="text-align:right;"| http://dir.xiph.org
|
| style="text-align:right;"| https://mf4.xiph.org
| tbr
|-
| [[Icecast]] Streams (Beta)
| style="text-align:right;"| http://dir-test.xiph.org
|
| style="text-align:right;"| https://catfish.xiph.org
| ePirat, tbr
|-
| Jenkins
| style="text-align:right;"| https://mf4.xiph.org/jenkins/
| jenkins
| style="text-align:right;"| https://mf4.xiph.org
| TD-Linux
|-
| Mail
| style="text-align:right;"| xiph.org
| mailfish
| style="text-align:right;"| https://catfish.xiph.org
| ePirat, tbr
|-
| MailMan
| style="text-align:right;"| http://lists.xiph.org
| mailfish
| style="text-align:right;"| https://catfish.xiph.org
| ePirat, tbr
|-
| Media
| style="text-align:right;"| https://media.xiph.org
|
| style="text-align:right;"| https://media.xiph.org
| TD-Linux
|-
| Opus Boodler Streams
| style="text-align:right;"| https://opus-codec.org
|
| style="text-align:right;"| https://mf4.xiph.org
| gmaxwell
|-
| Rietveld
| style="text-align:right;"| https://review.xiph.org
| jenkins
| style="text-align:right;"| https://mf4.xiph.org
| TD-Linux
|-
| Subversion Repos
| style="text-align:right;"| https://svn.xiph.org
|
| style="text-align:right;"| https://mf4.xiph.org
| rillian
|-
| Trac Bug Tracker
| style="text-align:right;"| https://trac.xiph.org
|
| style="text-align:right;"| https://mf4.xiph.org
| tbr
|-
| [[XiphWiki:Features|Wiki]]
| style="text-align:right;"| https://wiki.xiph.org
| [[XiphInfra:Wiki VM|wiki]]
| style="text-align:right;"| https://catfish.xiph.org
| ePirat
|-
| Xiph Mirror Repos
| style="text-align:right;"| https://github.com/xiph
|
|
| rillian
|-
| XiphBot-ng
| style="text-align:right;"| XiphWiki on freenode.net
|
| style="text-align:right;"| https://mf4.xiph.org
| TD-Linux
|-
| [[XiphInfra:Gitlab|Gitlab]]
| style="text-align:right;"| https://gitlab.xiph.org
| gitlab
| style="text-align:right;"| https://catfish.xiph.org
| ePirat (VM and Gitlab), tbr (VM and Gitlab), TD-Linux (Gitlab)
|}

<noinclude>See the [[XiphInfra:Overview|Overview]] page for more information.</noinclude>

OpusExtensions

2016-04-19T21:20:31Z

Rillian: merge sections

Opus audio data packets begin with a "table of contents" (TOC) sequence which defines the frame duration, audio bandwidth and coding mode of the packet, as well as describing how individual frames are packed into the data packet. [[https://tools.ietf.org/html/rfc6716#section-3.1 RFC 6716 Section 3.1]]. Other types of data packets are used with Opus in various containers are designed to start with a sequence which is not a valid TOC. This simplifies sorting such data for muxing implementations and ensures they will be rejected by the decoder if they are accidentally passed as Opus audio data.

Below is a list of such alternate sequences, to avoid duplication.

== List of reserved invalid Opus TOC sequences ==

* `Op` is used as a prefix for metadata headers in .opus files. [https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]
* '0x3FF' in the first 11 bits marks an `opus_control_header` in MPEG-TS. [[OpusTS]]

== Space of all invalid Opus TOC sequences ==

* 0x0300
* 0x030C...0x0340
* 0x034C...0x0380
* 0x038C...0x03C0
* 0x03CC...0x03FF

* 0x0700
* 0x070C...0x0740
* 0x074C...0x0780
* 0x078C...0x07C0
* 0x07CC...0x07FF

* 0x0B00
* 0x0B06...0x0B40
* 0x0B46...0x0B80
* 0x0B86...0x0BC0
* 0x0BC6...0x0BFF

* 0x0F00
* 0x0F06...0x0F40
* 0x0F46...0x0F80
* 0x0F86...0x0FC0
* 0x0FC6...0x0FFF

* 0x1300
* 0x1303...0x1340
* 0x1343...0x1380
* 0x1383...0x13C0
* 0x13C3...0x13FF

* 0x1700
* 0x1703...0x1740
* 0x1743...0x1780
* 0x1783...0x17C0
* 0x17C3...0x17FF

* 0x1B00
* 0x1B02...0x1B40
* 0x1B42...0x1B80
* 0x1B82...0x1BC0
* 0x1BC2...0x1BFF

* 0x1F00
* 0x1F02...0x1F40
* 0x1F42...0x1F80
* 0x1F82...0x1FC0
* 0x1FC2...0x1FFF

* 0x2300
* 0x230C...0x2340
* 0x234C...0x2380
* 0x238C...0x23C0
* 0x23CC...0x23FF

* 0x2700
* 0x270C...0x2740
* 0x274C...0x2780
* 0x278C...0x27C0
* 0x27CC...0x27FF

* 0x2B00
* 0x2B06...0x2B40
* 0x2B46...0x2B80
* 0x2B86...0x2BC0
* 0x2BC6...0x2BFF

* 0x2F00
* 0x2F06...0x2F40
* 0x2F46...0x2F80
* 0x2F86...0x2FC0
* 0x2FC6...0x2FFF

* 0x3300
* 0x3303...0x3340
* 0x3343...0x3380
* 0x3383...0x33C0
* 0x33C3...0x33FF

* 0x3700
* 0x3703...0x3740
* 0x3743...0x3780
* 0x3783...0x37C0
* 0x37C3...0x37FF

* 0x3B00
* 0x3B02...0x3B40
* 0x3B42...0x3B80
* 0x3B82...0x3BC0
* 0x3BC2...0x3BFF

* 0x3F00
* 0x3F02...0x3F40
* 0x3F42...0x3F80
* 0x3F82...0x3FC0
* 0x3FC2...0x3FFF

* 0x4300
* 0x430C...0x4340
* 0x434C...0x4380
* 0x438C...0x43C0
* 0x43CC...0x43FF

* 0x4700
* 0x470C...0x4740
* 0x474C...0x4780
* 0x478C...0x47C0
* 0x47CC...0x47FF

* 0x4B00
* 0x4B06...0x4B40
* 0x4B46...0x4B80
* 0x4B86...0x4BC0
* 0x4BC6...0x4BFF

* 0x4F00
* 0x4F06...0x4F40
* 0x4F46...0x4F6F
* 0x4F70 ("Op"): ID and Comment headers in .opus files [https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]
* 0x4F71...0x4F80
* 0x4F86...0x4FC0
* 0x4FC6...0x4FFF

* 0x5300
* 0x5303...0x5340
* 0x5343...0x5380
* 0x5383...0x53C0
* 0x53C3...0x53FF

* 0x5700
* 0x5703...0x5740
* 0x5743...0x5780
* 0x5783...0x57C0
* 0x57C3...0x57FF

* 0x5B00
* 0x5B02...0x5B40
* 0x5B42...0x5B80
* 0x5B82...0x5BC0
* 0x5BC2...0x5BFF

* 0x5F00
* 0x5F02...0x5F40
* 0x5F42...0x5F80
* 0x5F82...0x5FC0
* 0x5FC2...0x5FFF

* 0x6300
* 0x630C...0x6340
* 0x634C...0x6380
* 0x638C...0x63C0
* 0x63CC...0x63FF

* 0x6700
* 0x670C...0x6740
* 0x674C...0x6780
* 0x678C...0x67C0
* 0x67CC...0x67FF

* 0x6B00
* 0x6B06...0x6B40
* 0x6B46...0x6B80
* 0x6B86...0x6BC0
* 0x6BC6...0x6BFF

* 0x6F00
* 0x6F06...0x6F40
* 0x6F46...0x6F80
* 0x6F86...0x6FC0
* 0x6FC6...0x6FFF

* 0x7300
* 0x730C...0x7340
* 0x734C...0x7380
* 0x738C...0x73C0
* 0x73CC...0x73FF

* 0x7700
* 0x770C...0x7740
* 0x774C...0x7780
* 0x778C...0x77C0
* 0x77CC...0x77FF

* 0x7B00
* 0x7B06...0x7B40
* 0x7B46...0x7B80
* 0x7B86...0x7BC0
* 0x7BC6...0x7BFF

* 0x7F00
* 0x7F06...0x7F40
* 0x7F46...0x7F80
* 0x7F86...0x7FC0
* 0x7FC6...0x7FDF
* 0x7FE0...0x7FFF: opus_control_header in MPEG-TS [[OpusTS]]

* 0x8300
* 0x8330...0x8340
* 0x8370...0x8380
* 0x83B0...0x83C0
* 0x83F0...0x83FF

* 0x8700
* 0x8730...0x8740
* 0x8770...0x8780
* 0x87B0...0x87C0
* 0x87F0...0x87FF

* 0x8B00
* 0x8B18...0x8B40
* 0x8B58...0x8B80
* 0x8B98...0x8BC0
* 0x8BD8...0x8BFF

* 0x8F00
* 0x8F18...0x8F40
* 0x8F58...0x8F80
* 0x8F98...0x8FC0
* 0x8FD8...0x8FFF

* 0x9300
* 0x930C...0x9340
* 0x934C...0x9380
* 0x938C...0x93C0
* 0x93CC...0x93FF

* 0x9700
* 0x970C...0x9740
* 0x974C...0x9780
* 0x978C...0x97C0
* 0x97CC...0x97FF

* 0x9B00
* 0x9B06...0x9B40
* 0x9B46...0x9B80
* 0x9B86...0x9BC0
* 0x9BC6...0x9BFF

* 0x9F00
* 0x9F06...0x9F40
* 0x9F46...0x9F80
* 0x9F86...0x9FC0
* 0x9FC6...0x9FFF

* 0xA300
* 0xA330...0xA340
* 0xA370...0xA380
* 0xA3B0...0xA3C0
* 0xA3F0...0xA3FF

* 0xA700
* 0xA730...0xA740
* 0xA770...0xA780
* 0xA7B0...0xA7C0
* 0xA7F0...0xA7FF

* 0xAB00
* 0xAB18...0xAB40
* 0xAB58...0xAB80
* 0xAB98...0xABC0
* 0xABD8...0xABFF

* 0xAF00
* 0xAF18...0xAF40
* 0xAF58...0xAF80
* 0xAF98...0xAFC0
* 0xAFD8...0xAFFF

* 0xB300
* 0xB30C...0xB340
* 0xB34C...0xB380
* 0xB38C...0xB3C0
* 0xB3CC...0xB3FF

* 0xB700
* 0xB70C...0xB740
* 0xB74C...0xB780
* 0xB78C...0xB7C0
* 0xB7CC...0xB7FF

* 0xBB00
* 0xBB06...0xBB40
* 0xBB46...0xBB80
* 0xBB86...0xBBC0
* 0xBBC6...0xBBFF

* 0xBF00
* 0xBF06...0xBF40
* 0xBF46...0xBF80
* 0xBF86...0xBFC0
* 0xBFC6...0xBFFF

* 0xC300
* 0xC330...0xC340
* 0xC370...0xC380
* 0xC3B0...0xC3C0
* 0xC3F0...0xC3FF

* 0xC700
* 0xC730...0xC740
* 0xC770...0xC780
* 0xC7B0...0xC7C0
* 0xC7F0...0xC7FF

* 0xCB00
* 0xCB18...0xCB40
* 0xCB58...0xCB80
* 0xCB98...0xCBC0
* 0xCBD8...0xCBFF

* 0xCF00
* 0xCF18...0xCF40
* 0xCF58...0xCF80
* 0xCF98...0xCFC0
* 0xCFD8...0xCFFF

* 0xD300
* 0xD30C...0xD340
* 0xD34C...0xD380
* 0xD38C...0xD3C0
* 0xD3CC...0xD3FF

* 0xD700
* 0xD70C...0xD740
* 0xD74C...0xD780
* 0xD78C...0xD7C0
* 0xD7CC...0xD7FF

* 0xDB00
* 0xDB06...0xDB40
* 0xDB46...0xDB80
* 0xDB86...0xDBC0
* 0xDBC6...0xDBFF

* 0xDF00
* 0xDF06...0xDF40
* 0xDF46...0xDF80
* 0xDF86...0xDFC0
* 0xDFC6...0xDFFF

* 0xE300
* 0xE330...0xE340
* 0xE370...0xE380
* 0xE3B0...0xE3C0
* 0xE3F0...0xE3FF

The only restriction that doesn't depend on the number of bytes
in the packet is [R5], which is, "Code 3 packets contain at least
one frame, but no more than 120 ms of audio total."
* 0xE700
* 0xE730...0xE740
* 0xE770...0xE780
* 0xE7B0...0xE7C0
* 0xE7F0...0xE7FF

* 0xEB00
* 0xEB18...0xEB40
* 0xEB58...0xEB80
* 0xEB98...0xEBC0
* 0xEBD8...0xEBFF

* 0xEF00
* 0xEF18...0xEF40
* 0xEF58...0xEF80
* 0xEF98...0xEFC0
* 0xEFD8...0xEFFF

* 0xF300
* 0xF30C...0xF340
* 0xF34C...0xF380
* 0xF38C...0xF3C0
* 0xF3CC...0xF3FF

* 0xF700
* 0xF70C...0xF740
* 0xF74C...0xF780
* 0xF78C...0xF7C0
* 0xF7CC...0xF7FF

* 0xFB00
* 0xFB06...0xFB40
* 0xFB46...0xFB80
* 0xFB86...0xFBC0
* 0xFBC6...0xFBFF

* 0xFF00
* 0xFF06...0xFF40
* 0xFF46...0xFF80
* 0xFF86...0xFFC0
* 0xFFC6...0xFFFF

OpusExtensions

2016-04-19T20:50:08Z

Rillian: Derf's braindump from IRC

OpusExtensions

2016-04-19T20:47:12Z

Rillian: opus_audio_descriptor isn't a PES packet, and starts with a valid TOC, so it doesn't belong on this list.

OpusExtensions

2016-04-19T20:32:46Z

Rillian:

OpusExtensions

2016-04-19T20:20:38Z

Rillian: fix references

OpusExtensions

2016-04-19T20:19:51Z

Rillian: Update mpeg-ts

OpusExtensions

2016-04-19T19:51:37Z

Rillian: Start a page to track invalid TOC sequences used for extensions.

OpusTodo

2016-01-13T18:29:11Z

Rillian: Link mp4 draft.

== For 1.1.3 ==
* aarch64 and AVX optimizations

== For 1.2 ==
* Low bitrate quality improvements
* Fix compilation as a single module for gecko

== Spec ==
* Ogg mapping. See [[https://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation
* RTP payload format. Mono/stereo mapping is complete [[https://tools.ietf.org/html/rfc7587 RFC 7587]], no multichannel mapping yet.
* mp4 mapping. See [[https://opus-codec.org/docs/opus_in_isobmff.html ISO Base Media File Format draft]]

== Website ==
* De-uglify webpage - some suggestions:
** write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?) and the proprietary ones)
** write about implementations (libopus encoder/decoder, libavcodec decoder, any others?)
** [https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats audio codec comparison table] (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...)
** future use in video files (Theora? Dirac? WebM? other future codecs...)
** audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ...
* Promotional material (some nice free/public-domain sounds/radio stations in Opus format)

== Other ==

* Oggz-validate (should also validate opus toc)

== Opus-tools ==
* Port opusdec to libopusfile/libopusurl.
* A simple real time streaming example tool
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?
** Make --sniff save one file per
** Implement DTLS-SRTP. See webrtc.
** audio capture/encode, decode/playback?
** Parse and act on sdp for convenience and testing.

* EBU R128/Replaygain (half done— needs a gain tool)

== Surround work ==

* Apply spreading to energy masking
* More conservative energy masking (not just mean difference) and dynalloc
* Allow SILK/hybrid on center channel for voice?

== Psychoacoustic stuff ==

* Adaptive width narrowing and forced intensity stereo bands

== Optimisations ==

* Vectorising comb_filter()
* Use 16-bit mul plus shift in denormalise_bands()
* Optimise MDCT somehow

== Third-Party tool enhancements ==
* mutagen: [https://bitbucket.org/lazka/mutagen/issue/202/oggopus-support-in-place-rewrites-for support padding in comments header], [https://bitbucket.org/lazka/mutagen/issue/203/oggopus-allow-updating-the-output_gain allow updating output gain in ID header]

== Future work ==
* psymodel based VBR
* Remove copy in inverse MDCT
* Save some float<->int conversions
* Improvements to LP mode CBR (greg has some code)
* Unconstrained SILK VBR
* Better handling for the case where FEC has a different bandwidth than the current mode
* PLC transitions on unprotected SILK-SILK bandwidth changes?
* Figure out how to use speech/music detection optimally
** find optimal switching time (low energy/tonality)
* Improve variable frame size

[[Category:Opus]]

OpusTodo

2016-01-13T18:27:53Z

Rillian: mention unified build bugs

== For 1.1.3 ==
* aarch64 and AVX optimizations

== For 1.2 ==
* Low bitrate quality improvements
* Fix compilation as a single module for gecko

== Spec ==
* Ogg mapping. See [[https://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation
* RTP payload format. Mono/stereo mapping is complete [[https://tools.ietf.org/html/rfc7587 RFC 7587]], no multichannel mapping yet.

== Website ==
* De-uglify webpage - some suggestions:
** write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?) and the proprietary ones)
** write about implementations (libopus encoder/decoder, libavcodec decoder, any others?)
** [https://en.wikipedia.org/wiki/Comparison_of_audio_coding_formats audio codec comparison table] (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...)
** future use in video files (Theora? Dirac? WebM? other future codecs...)
** audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ...
* Promotional material (some nice free/public-domain sounds/radio stations in Opus format)

== Other ==

* Oggz-validate (should also validate opus toc)

== Opus-tools ==
* Port opusdec to libopusfile/libopusurl.
* A simple real time streaming example tool
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?
** Make --sniff save one file per
** Implement DTLS-SRTP. See webrtc.
** audio capture/encode, decode/playback?
** Parse and act on sdp for convenience and testing.

* EBU R128/Replaygain (half done— needs a gain tool)

== Surround work ==

* Apply spreading to energy masking
* More conservative energy masking (not just mean difference) and dynalloc
* Allow SILK/hybrid on center channel for voice?

== Psychoacoustic stuff ==

* Adaptive width narrowing and forced intensity stereo bands

== Optimisations ==

* Vectorising comb_filter()
* Use 16-bit mul plus shift in denormalise_bands()
* Optimise MDCT somehow

== Third-Party tool enhancements ==
* mutagen: [https://bitbucket.org/lazka/mutagen/issue/202/oggopus-support-in-place-rewrites-for support padding in comments header], [https://bitbucket.org/lazka/mutagen/issue/203/oggopus-allow-updating-the-output_gain allow updating output gain in ID header]

== Future work ==
* psymodel based VBR
* Remove copy in inverse MDCT
* Save some float<->int conversions
* Improvements to LP mode CBR (greg has some code)
* Unconstrained SILK VBR
* Better handling for the case where FEC has a different bandwidth than the current mode
* PLC transitions on unprotected SILK-SILK bandwidth changes?
* Figure out how to use speech/music detection optimally
** find optimal switching time (low energy/tonality)
* Improve variable frame size

[[Category:Opus]]

MIMETypesCodecs

2015-11-17T23:12:30Z

Rillian: /* MIME Types */ Add Opus to the audio/ogg table

== Specification of MIME types and respective codecs parameter ==

Also includes a specification of the recommended file extensions to use with Ogg.

=== MIME Types ===

The following MIME types are now officially registered with IANA and specified with the IETF as [http://www.ietf.org/rfc/rfc5334.txt RFC 5334]:

{| class="wikitable" style="text-align: center;"
|-
! MIME Type
! Use
! [[Ogg Skeleton|Skeleton]] logical stream?
! File Extension(s)
! Macintosh File Type Code
|-
| video/ogg
| video (possibly with audio) 
encapsulated in Ogg
| recommended
| .ogv
| OggV
|-
| audio/ogg
| audio encapsulated in Ogg
| recommended
| .oga 
.ogg ([[Vorbis]] I) 
.opus ([[Opus]]) 
.spx ([[Speex]])
| OggA
|-
| application/ogg
| complex/multitrack/multiplexed files 
encapsulated in Ogg
| required
| .ogx
| OggX
|}

[[MIME_Types_and_File_Extensions|Other MIME types]] are still in the registration process.

=== Codecs Parameter ===

[http://www.rfc-editor.org/rfc/rfc4281.txt Typically], MIME types of media encapsulation formats use the optional "codecs" parameter to specify which codecs are being used in a particular file.

Codecs encapsulated in Ogg require a text identifier at the beginning of the first header page to identify the encapsulated codecs.

The following table contains the identifiers for existing Xiph codecs and the codec parameter names used for */ogg MIME types (in alphabetical order):

{| class="wikitable" border="1"
|-
! Codecs Parameter Name
! Codec Type
! Codec Identifier
(decimal, hex, octal)
! Version Field (if available)
|-
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h celt]
| audio
| char[0,8]: <tt>'CELT\ \ \ \ '</tt>
hex: <tt>'0x43 0x45 0x4c 0x54 0x20 0x20 0x20 0x20'</tt>

oct: <tt>'0103 0105 0114 0124 0040 0040 0040 0040'</tt>
| char[28,4]: version id
|-
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h cmml]
| text
| char[0,8]: <tt>'CMML\0\0\0\0'</tt>
hex: <tt>'0x43 0x4d 0x4d 0x4c 0x00 0x00 0x00 0x00'</tt>

oct: <tt>'0103 0115 0115 0114 0000 0000 0000 0000'</tt>
| char[8,2]: major version number,
char[10,2]: minor version number
|-
| [[OggDirac|dirac]]
| video
| char[0,5]: <tt>'BBCD\0'</tt>
hex: <tt>'0x42 0x42 0x43 0x44 0x00'</tt>

oct: <tt>'0102 0102 0103 0104 0000'</tt>
| ??
|-
| [http://flac.sourceforge.net/ogg_mapping.html flac]
| audio
| char[0,5]: <tt>'\177FLAC'</tt>
hex: <tt>'0x7F 0x46 0x4C 0x41 0x43'</tt>

oct: <tt>'0177 0106 0114 0101 0103'</tt>
| char[5,1]: binary major version number,
char[6,1]: binary minor version number of mapping
|-
| [[OggMNG|jng]]
| video
| char[0,8]: <tt>'\213JNG\r\n\032\n'</tt>
hex: <tt>'0x8b 0x4a 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt>

oct: <tt>'0213 0112 0116 0107 0015 0012 0032 0012'</tt>
| ??
|-
| [[OggKate|kate]]
| text
| char[0,8]: <tt>'\x80kate\0\0\0'</tt>
hex: <tt>'0x80 0x6b 0x61 0x74 0x65 0x00 0x00 0x00'</tt>

oct: <tt>'0200 0153 0141 0164 0145 0000 0000 0000'</tt>
| char[9,1]: major version number,
char[10,1]: minor version number
|-
| [http://lists.xiph.org/pipermail/vorbis-dev/2001-August/004501.html midi]
| text
| char[0,8]: <tt>'OggMIDI\0'</tt>
hex: <tt>'0x4f 0x67 0x67 0x4d 0x49 0x44 0x49 0x00'</tt>

oct: <tt>'0117 0147 0147 0115 0111 0104 0111 0000'</tt>
| char[8,1]: version field
|-
| [[OggMNG|mng]]
| video
| char[0,8]: <tt>'\212MNG\r\n\032\n'</tt>
hex: <tt>'0x8a 0x4d 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt>

oct: <tt>'0212 0115 0116 0107 0015 0012 0032 0012'</tt>
| ??
|-
| [[OggOpus|opus]]
| audio
| char[0,8]: <tt>'OpusHead'</tt>
hex: <tt>'0x4f 0x70 0x75 0x73 0x48 0x65 0x61 0x64'</tt>

oct: <tt>'0117 0160 0165 0163 0110 0150 0141 0145 1044'</tt>
| char[8,1]: version field
|-
| [[OggPCM|pcm]]
| audio
| char[0,8]: <tt>'PCM\ \ \ \ \ '</tt>
hex: <tt>'0x50 0x43 0x4d 0x20 0x20 0x20 0x20 0x20'</tt>

oct: <tt>'0120 0103 0115 0040 0040 0040 0040 0040'</tt>
| char[8,2]: version major field,
char[10,2]: version minor field
|-
| [[OggMNG|png]]
| video
| char[0,8]: <tt>'\211PNG\r\n\032\n'</tt>
hex: <tt>'0x89 0x50 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt>

oct: <tt>'0211 0120 0116 0107 0015 0012 0032 0012'</tt>
| ??
|-
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h speex]
| audio
| char[0,8]: <tt>'Speex\ \ \ '</tt>
hex: <tt>'0x53 0x70 0x65 0x65 0x78 0x20 0x20 0x20'</tt>

oct: <tt>'0123 0160 0145 0145 0170 0040 0040 0040'</tt>
| char[28,4]: version id
|-
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h theora]
| video
| char[0,7]: <tt>'\x80theora'</tt>
hex: <tt>'0x80 0x74 0x68 0x65 0x6f 0x72 0x61'</tt>

oct: <tt>'0180 0164 0150 0145 0157 0162 0141'</tt>
| char[7,1]: major version number,
char[8,1]: minor version number,

char[9,1]: version revision number
|-
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h vorbis]
| audio
| char[0,7]: <tt>'\x01vorbis'</tt>
hex: <tt>'0x01 0x76 0x6f 0x72 0x62 0x69 0x73'</tt>

oct: <tt>'0001 0166 0157 0162 0142 0151 0163'</tt>
| char[7,4]: version field
|-
| [[OggYUV4MPEG|yuv4mpeg]]
| video
| char[0,8]: <tt>'YUV4MPEG'</tt>
hex: <tt>'0x59 0x55 0x56 0x34 0x4d 0x50 0x45 0x47'</tt>

oct: <tt>'0131 0125 0126 0064 0115 0120 0105 0107'</tt>
| char[8,1] = '2' (0x32) for yuv4mpeg format version 2
|}

The "char[x,y]" fields mean here: start at byte number x (counting from 0) for a length of y bytes.

[[Category:Ogg]]

AdminProcesses

2015-05-09T23:28:52Z

Rillian: /* Administration Information */ Update some responsibilities

= Administration Information =

Xiph is a benevolent dictatorship led by Monty, but decisions on administrative things are delegated to a committee. The committee consists of Monty, Ralph Giles, Jack Mofitt, j^, and Silvia Pfeiffer.

=== Formats/Projects ===
* [http://en.wikipedia.org/wiki/Annodex Annodex]: Silvia Pfeiffer, Conrad Parker
* [[CMML]]: Silvia Pfeiffer, Conrad Parker
* [[FLAC]]: Erik de Castro Lopo
* [[Icecast]]: Thomas Rücker
* [[Skeleton]]: Conrad Parker
* [[Speex]]: [[User:jmspeex|Jean-Marc Valin]]
* [[Opus]]: [[User:jmspeex|Jean-Marc Valin]]
* [[Theora]]: Ralph Giles
* [[Daala]]: Tim Terriberry, Jack Moffitt
* [[Vorbis]]: Monty
* [[XSPF]]: Lucas Gonze, [[User:Saoshyant|Ivo Emanuel Gonçalves]], [[User:Sping|Sebastian Pipping]]

=== Other ===
* [[Spread Open Media]]: [[User:Saoshyant|Ivo Emanuel Gonçalves]]
* Xiph Web: ePirat
* Xiph Wiki: ePirate, j^
* Xiph SVN: j^

== Decision process ==

Anything that looks like it's officially authorised by Xiph needs approval.

This may be something that goes on the web or on the wiki or anywhere else.

If you would like something to as officially authorised, get approval from somebody on the committee (ultimately from Monty if it's unresolvable) beforehand.

For web pages, you should in particular not edit them in svn or send a patch to the web maintainer unless you have approval.

== See also ==
* the [[People]] page for an overview of everyone in Xiph

AdminProcesses

2015-05-09T23:26:02Z

Rillian: /* Formats/Projects */ Add Opus and Daala

= Administration Information =

Xiph is a benevolent dictatorship led by Monty, but decisions on administrative things are delegated to a committee. The committee consists of Monty, Ralph Giles, Jack Mofitt, j^, Mike Smith, Zentaro Kavanagh, and Silvia Pfeiffer.

=== Formats/Projects ===
* [http://en.wikipedia.org/wiki/Annodex Annodex]: Silvia Pfeiffer, Conrad Parker
* [[CMML]]: Silvia Pfeiffer, Conrad Parker
* [[FLAC]]: Erik de Castro Lopo
* [[Icecast]]: Mike Smith
* [[Skeleton]]: Conrad Parker
* [[Speex]]: [[User:jmspeex|Jean-Marc Valin]]
* [[Opus]]: [[User:jmspeex|Jean-Marc Valin]]
* [[Theora]]: Ralph Giles
* [[Daala]]: Tim Terryberry, Jack Moffitt
* [[Vorbis]]: Monty
* [[XSPF]]: Lucas Gonze, [[User:Saoshyant|Ivo Emanuel Gonçalves]], [[User:Sping|Sebastian Pipping]]

=== Other ===
* [[Spread Open Media]]: [[User:Saoshyant|Ivo Emanuel Gonçalves]]
* Xiph Web: Atamido
* Xiph Wiki: j^
* Xiph SVN: j^

== Decision process ==

Anything that looks like it's officially authorised by Xiph needs approval.

This may be something that goes on the web or on the wiki or anywhere else.

If you would like something to as officially authorised, get approval from somebody on the committee (ultimately from Monty if it's unresolvable) beforehand.

For web pages, you should in particular not edit them in svn or send a patch to the web maintainer unless you have approval.

== See also ==
* the [[People]] page for an overview of everyone in Xiph

XiphWiki:Features

2015-04-30T14:59:25Z

Rillian: /* Ogg Media Player removed */ Xiph generally doesn't use ffmpeg/libav. We prefer to receive and share only libre formats like ogg, webm, opus and soon mp3.

Recently this Wiki, which is powered by MediaWiki, was updated to [https://www.mediawiki.org/wiki/MediaWiki_1.24 MediaWiki 1.24] (the previous version we used was 1.16). 
This was a huge update, as 1.16 was released in the end of 2010 (it was nearly 5 years old!).

== New Features ==
With the update to the new MediaWiki version, there are some new features which are explained in detail in this section.

=== Skin ===
One of the most noticeable new ‘features’ is probably the new design.

We used to have an old custom version of the MonoBook skin, which was hacked together a bit and I was unable to migrate it to the new version. Therefore we are currently using the [http://www.mediawiki.org/wiki/Skin:Vector Vector] skin with a squared version of the Xiph.Org logo. It's an SVG so that it looks nice on HiDPI screens. If anyone discovers any problems with it, please leave a note on the [[{{TALKPAGENAME}}|Discussion]] for this article. Please note that '''the current Skin is not the final version''' and will be adapted to look more Xiph-like. This is a very controversial topic, as design choices always are, so some feedback about it on the [[{{TALKPAGENAME}}|Discussion]] would be nice. If a lot of people really want the old Design back, it could be recreated based on MonoBook, but if you only want a more flat-ish look, just switch to MonoBook in your [[Special:Preferences|preferences]].

=== HiDPI Images ===
Everyone that has a [http://en.wikipedia.org/wiki/Retina_Display HiDPI (Retina)] Display can enjoy the new [http://www.mediawiki.org/wiki/HiDPI_display_support HiDPI Display Support]!

What does that mean? MediaWiki will generate scaled images, as you might know. It used to only generate them with normal DPI, with HiDPI it will generate these scaled images in a high resolution version, so that they display nicely on screens that can handle them. This is done using the ''srcset'' attribute of the image tag. If you are running a not so ancient browser, it is likely to work just fine and choose the correct image for you.

=== Syntax Highlighting ===
Yes, finally the Wiki is able to do syntax highlighting.

This is done using the [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi SyntaxHighlight GeSHi] extension, which is bundled since some time with MediaWiki now. If you want to insert syntax-highlighted code, use the following:

<pre><nowiki><syntaxhighlight lang="php">
<?php $coolcode = false; ?>
</syntaxhighlight></nowiki></pre>

which would produce following output:

<syntaxhighlight lang="php">
<?php $coolcode = false; ?>
</syntaxhighlight>

As you can see there are specific parameters you pass as attributes/values, one is the <code>lang</code>, which specifies the language. For a list of supported languages and more parameters that you can use, please refer to the [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi#Supported_languages SyntaxHighlight GeSHi Wiki Page].

=== Mobile View ===
I installed the [http://www.mediawiki.org/wiki/Extension:MobileFrontend MobileFrontend] extension, which provides a mobile Version of the Wiki for Smartphones, which is much easier to read than with the normal Vector Skin. It currently uses the default configuration.

=== License Notes ===
I have set-up license information according to the [[XiphWiki:Copyrights|Copyrights]] page, so now there is the license information on any page footer and in the editor when you are writing a new page.

== Changed behavior ==
With the new Version, some things that were possible before are not possible anymore, this section details on those things. If you think, any of the changes below are a critical impact on the Wiki behavior, leave a note on the [[{{TALKPAGENAME}}|Discussion]] and we can investigate how to solve it.

=== Visitor count ===
Every page now again has a visitor count which displays the number of people that have visited the Page. This was turned off in the old configuration, but as the configuration option to do this is now deprecated, it is turned on again.

=== News Channel removed ===
The [http://www.mediawiki.org/wiki/Extension:News_Channel News Channel] Extension was removed, as I couldn't find any page that was actually using it. The category for which it was configured was empty, therefore it did not made much sense to keep it around. Additionally I wasn't able to find a proper download source which I fully trusted.

=== Ogg Media Player removed ===
The [http://www.mediawiki.org/wiki/Extension:OggHandler OggHandler] extension which provided a Java Media Player (who does use Java anymore anyway?) and some information about Ogg Media files that are uploaded to the Wiki. As this extension now is obsolete I did not install it, the extension suggested as replacement is very complicated and I think it does more than we could ever need. One of the main problems is that Xiph doesn't support non-free media formats, so it is not possible to use TimedMediaHandler anyway. (The OggHandler was not configured properly as well, it seems.)

== Administration Information ==
This section is intended for anyone that needs to ever update the Wiki to a new version or wants to change it's config or add a new Skin or Extension.

All configuration changes must be done in the LocalSettings.php file, nowhere else! If you change something or add something, please add it to the right location, I tried to structure the file in a meaningful way using a lot of comments to make it as easy as possible to edit it. If you can't find a section your config option that needs to be adjusted fits in, add it at the end in front of the Extension includes/config part!
Write a short comment about what the option you add does and, if it is not clear, why this is needed.

If you install a new extension, make sure it is really needed and that it is supported (check the MediaWiki Extension Page) for the current MediaWiki Version. If in doubt of it's quality, possibly have a quick look at the code for any suspicious things like bad code quality (wrong indentation, no comments at all…) or weird eval's!

Some notes about the Apache configuration: It is a bit horrible (sorry). I just kept the old one and added the needed new files as it hardcodes all php files and folders that need to be accessed, even two times. (One time for SSL and another time for non-SSL) this should be improved by someone that has good Apache config skills (I am more familiar with nginx).

Thanks for reading! Happy Wiki-editing.

Summer of Code Mentoring

2015-02-20T06:42:41Z

Rillian: /* Questionaire for 2015 */ Move answer to the correct question.

== Xiph.Org Application as a mentoring organization ==

We need to apply for consideration as a mentoring organization 2015 February 9 - 20. Google lists the following questions in their [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#1._How_does_a_mentoring_organization faq]. Our work-in-progress answers are inline.

==== Describe your organization. ====

The Xiph.Org Foundation is a 501(c)(3) non-profit organization dedicated to providing open and free-to-implement multimedia technology as a foundation for an interoperable, level playing field on the Internet and other digital distribution networks. Over the past 14 years we have developed most of the major patent-free and royalty-free audio and video codecs currently in use, including Opus, Vorbis, Speex, FLAC and Theora, as well as developing the Ogg streaming format, and the Icecast streaming media server. Xiph hosted libraries like liboggplay and liboggz power the underling html5 video support in Mozilla Firefox.

==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

==== Has your organization participated in past Google Summer of Codes? ====

Yes

==== If you answered “yes” to the question above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were [http://code.google.com/soc/xiph/about.html successful]. One, a [http://code.google.com/soc/xiph/appinfo.html?csaid=5F9265EEC6FA0611 hardware implementation of a Theora decoder]: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, [http://code.google.com/soc/xiph/appinfo.html?csaid=213E2D30F095565D implementation of OggSkeleton support] in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation over the last years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity, reset and be part in this years Summer of code with a focus on Icecast, also avoiding the previous emphasis on codecs, as it proved very challenging to most student participants.

==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====

We have participated previously, in 2006, 2007, 2008 and 2009.
We applied in 2010, but weren't chosen.

==== What Open Source Initiative approved license(s) does your project use? ====

In general, we use the revised 3-clause BSD license for our libraries, to enable the widest possible uses of our formats and reference implementations.

Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.

==== What is the URL for your Ideas list? ====

http://wiki.xiph.org/Summer_of_Code_2015

==== What is the main development mailing list for your organization? ====

Icecast will be the main Xiph.org project for GSoC this year.

[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]

[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]

A complete listing of our lists is available at:

http://lists.xiph.org/mailman/listinfo/

==== What is the main IRC channel for your organization? ====

The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]

==== Who will be your backup organization administrator? ====

'''tbd'''

==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====

http://wiki.xiph.org/index.php/Summer_of_Code_Applications

==== What criteria did you use to select the mentors? Please be as specific as possible. ====

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

'''''TODO: Introduce mentors briefly.'''''
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====
Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====

We are a well established organization and participated in GSoC in the past.

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====

==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

==== Additional items not listed by the GSoC FAQ ====
===== Who will be your main organization administrator =====

Thomas B. Rücker, maintainer of the Icecast project.

===== Who will your mentors be? =====

* '''Thomas B. Rücker''' - IRC nick: ''tbr''
* '''NN''' - IRC nick:

== Questionaire for 2015 ==

=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

=== If you chose "veteran" in the checkbox, please summarize your involvement in Google Summer of Code and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ===

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were successful. One, a hardware implementation of a Theora decoder: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, implementation of OggSkeleton support in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation during past years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity to reset and be part in this year's Summer of Code with a focus on Icecast.

=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team. This focus will avoid the previous emphasis on codecs, which proved very challenging to most student participants.

=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===

Three mentors have volunteered.

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

=== What is your plan for dealing with disappearing students? ===

Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

=== What is your plan for dealing with disappearing mentors? ===

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

=== What steps will you take to encourage students to interact with your project's community before and during the program? ===

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===

We are a well established organization and participated in GSoC in the past.

=== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ===

=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===

Summer of Code Mentoring

2015-02-20T06:32:01Z

Rillian: /* How many potential mentors do you have for this year's program? What criteria did you use to select them? */ stephenj has also volunteered to mentor.

== Xiph.Org Application as a mentoring organization ==

We need to apply for consideration as a mentoring organization 2015 February 9 - 20. Google lists the following questions in their [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#1._How_does_a_mentoring_organization faq]. Our work-in-progress answers are inline.

==== Describe your organization. ====

The Xiph.Org Foundation is a 501(c)(3) non-profit organization dedicated to providing open and free-to-implement multimedia technology as a foundation for an interoperable, level playing field on the Internet and other digital distribution networks. Over the past 14 years we have developed most of the major patent-free and royalty-free audio and video codecs currently in use, including Opus, Vorbis, Speex, FLAC and Theora, as well as developing the Ogg streaming format, and the Icecast streaming media server. Xiph hosted libraries like liboggplay and liboggz power the underling html5 video support in Mozilla Firefox.

==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

==== Has your organization participated in past Google Summer of Codes? ====

Yes

==== If you answered “yes” to the question above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were [http://code.google.com/soc/xiph/about.html successful]. One, a [http://code.google.com/soc/xiph/appinfo.html?csaid=5F9265EEC6FA0611 hardware implementation of a Theora decoder]: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, [http://code.google.com/soc/xiph/appinfo.html?csaid=213E2D30F095565D implementation of OggSkeleton support] in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation over the last years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity, reset and be part in this years Summer of code with a focus on Icecast, also avoiding the previous emphasis on codecs, as it proved very challenging to most student participants.

==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====

We have participated previously, in 2006, 2007, 2008 and 2009.
We applied in 2010, but weren't chosen.

==== What Open Source Initiative approved license(s) does your project use? ====

In general, we use the revised 3-clause BSD license for our libraries, to enable the widest possible uses of our formats and reference implementations.

Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.

==== What is the URL for your Ideas list? ====

http://wiki.xiph.org/Summer_of_Code_2015

==== What is the main development mailing list for your organization? ====

Icecast will be the main Xiph.org project for GSoC this year.

[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]

[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]

A complete listing of our lists is available at:

http://lists.xiph.org/mailman/listinfo/

==== What is the main IRC channel for your organization? ====

The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]

==== Who will be your backup organization administrator? ====

'''tbd'''

==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====

http://wiki.xiph.org/index.php/Summer_of_Code_Applications

==== What criteria did you use to select the mentors? Please be as specific as possible. ====

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

'''''TODO: Introduce mentors briefly.'''''
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====
Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====

We are a well established organization and participated in GSoC in the past.

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====

==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

==== Additional items not listed by the GSoC FAQ ====
===== Who will be your main organization administrator =====

Thomas B. Rücker, maintainer of the Icecast project.

===== Who will your mentors be? =====

* '''Thomas B. Rücker''' - IRC nick: ''tbr''
* '''NN''' - IRC nick:

== Questionaire for 2015 ==

=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

=== If you chose "veteran" in the checkbox, please summarize your involvement in Google Summer of Code and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ===

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were successful. One, a hardware implementation of a Theora decoder: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, implementation of OggSkeleton support in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation during past years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity to reset and be part in this year's Summer of Code with a focus on Icecast.

=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team. This focus will avoid the previous emphasis on codecs, which proved very challenging to most student participants.

=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===

Three mentors have volunteered.

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

=== What is your plan for dealing with disappearing students? ===

Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

=== What is your plan for dealing with disappearing mentors? ===

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

=== What steps will you take to encourage students to interact with your project's community before and during the program? ===

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===

=== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ===

We are a well established organization and participated in GSoC in the past.

=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===

Summer of Code Mentoring

2015-02-20T06:27:37Z

Rillian: /* Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? */

== Xiph.Org Application as a mentoring organization ==

We need to apply for consideration as a mentoring organization 2015 February 9 - 20. Google lists the following questions in their [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#1._How_does_a_mentoring_organization faq]. Our work-in-progress answers are inline.

==== Describe your organization. ====

The Xiph.Org Foundation is a 501(c)(3) non-profit organization dedicated to providing open and free-to-implement multimedia technology as a foundation for an interoperable, level playing field on the Internet and other digital distribution networks. Over the past 14 years we have developed most of the major patent-free and royalty-free audio and video codecs currently in use, including Opus, Vorbis, Speex, FLAC and Theora, as well as developing the Ogg streaming format, and the Icecast streaming media server. Xiph hosted libraries like liboggplay and liboggz power the underling html5 video support in Mozilla Firefox.

==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

==== Has your organization participated in past Google Summer of Codes? ====

Yes

==== If you answered “yes” to the question above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were [http://code.google.com/soc/xiph/about.html successful]. One, a [http://code.google.com/soc/xiph/appinfo.html?csaid=5F9265EEC6FA0611 hardware implementation of a Theora decoder]: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, [http://code.google.com/soc/xiph/appinfo.html?csaid=213E2D30F095565D implementation of OggSkeleton support] in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation over the last years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity, reset and be part in this years Summer of code with a focus on Icecast, also avoiding the previous emphasis on codecs, as it proved very challenging to most student participants.

==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====

We have participated previously, in 2006, 2007, 2008 and 2009.
We applied in 2010, but weren't chosen.

==== What Open Source Initiative approved license(s) does your project use? ====

In general, we use the revised 3-clause BSD license for our libraries, to enable the widest possible uses of our formats and reference implementations.

Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.

==== What is the URL for your Ideas list? ====

http://wiki.xiph.org/Summer_of_Code_2015

==== What is the main development mailing list for your organization? ====

Icecast will be the main Xiph.org project for GSoC this year.

[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]

[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]

A complete listing of our lists is available at:

http://lists.xiph.org/mailman/listinfo/

==== What is the main IRC channel for your organization? ====

The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]

==== Who will be your backup organization administrator? ====

'''tbd'''

==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====

http://wiki.xiph.org/index.php/Summer_of_Code_Applications

==== What criteria did you use to select the mentors? Please be as specific as possible. ====

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

'''''TODO: Introduce mentors briefly.'''''
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====
Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====

We are a well established organization and participated in GSoC in the past.

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====

==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

==== Additional items not listed by the GSoC FAQ ====
===== Who will be your main organization administrator =====

Thomas B. Rücker, maintainer of the Icecast project.

===== Who will your mentors be? =====

* '''Thomas B. Rücker''' - IRC nick: ''tbr''
* '''NN''' - IRC nick:

== Questionaire for 2015 ==

=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

=== If you chose "veteran" in the checkbox, please summarize your involvement in Google Summer of Code and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ===

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were successful. One, a hardware implementation of a Theora decoder: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, implementation of OggSkeleton support in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation during past years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity to reset and be part in this year's Summer of Code with a focus on Icecast.

=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team. This focus will avoid the previous emphasis on codecs, which proved very challenging to most student participants.

=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===

Two mentors have volunteered.

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

=== What is your plan for dealing with disappearing students? ===

Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

=== What is your plan for dealing with disappearing mentors? ===

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

=== What steps will you take to encourage students to interact with your project's community before and during the program? ===

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===

=== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ===

We are a well established organization and participated in GSoC in the past.

=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===

Summer of Code Mentoring

2015-02-20T06:27:06Z

Rillian: /* Questionaire for 2015 */ Move codec sentence to goals section

== Xiph.Org Application as a mentoring organization ==

We need to apply for consideration as a mentoring organization 2015 February 9 - 20. Google lists the following questions in their [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#1._How_does_a_mentoring_organization faq]. Our work-in-progress answers are inline.

==== Describe your organization. ====

The Xiph.Org Foundation is a 501(c)(3) non-profit organization dedicated to providing open and free-to-implement multimedia technology as a foundation for an interoperable, level playing field on the Internet and other digital distribution networks. Over the past 14 years we have developed most of the major patent-free and royalty-free audio and video codecs currently in use, including Opus, Vorbis, Speex, FLAC and Theora, as well as developing the Ogg streaming format, and the Icecast streaming media server. Xiph hosted libraries like liboggplay and liboggz power the underling html5 video support in Mozilla Firefox.

==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

==== Has your organization participated in past Google Summer of Codes? ====

Yes

==== If you answered “yes” to the question above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were [http://code.google.com/soc/xiph/about.html successful]. One, a [http://code.google.com/soc/xiph/appinfo.html?csaid=5F9265EEC6FA0611 hardware implementation of a Theora decoder]: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, [http://code.google.com/soc/xiph/appinfo.html?csaid=213E2D30F095565D implementation of OggSkeleton support] in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation over the last years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity, reset and be part in this years Summer of code with a focus on Icecast, also avoiding the previous emphasis on codecs, as it proved very challenging to most student participants.

==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====

We have participated previously, in 2006, 2007, 2008 and 2009.
We applied in 2010, but weren't chosen.

==== What Open Source Initiative approved license(s) does your project use? ====

In general, we use the revised 3-clause BSD license for our libraries, to enable the widest possible uses of our formats and reference implementations.

Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.

==== What is the URL for your Ideas list? ====

http://wiki.xiph.org/Summer_of_Code_2015

==== What is the main development mailing list for your organization? ====

Icecast will be the main Xiph.org project for GSoC this year.

[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]

[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]

A complete listing of our lists is available at:

http://lists.xiph.org/mailman/listinfo/

==== What is the main IRC channel for your organization? ====

The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]

==== Who will be your backup organization administrator? ====

'''tbd'''

==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====

http://wiki.xiph.org/index.php/Summer_of_Code_Applications

==== What criteria did you use to select the mentors? Please be as specific as possible. ====

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

'''''TODO: Introduce mentors briefly.'''''
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====
Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====

We are a well established organization and participated in GSoC in the past.

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====

==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

==== Additional items not listed by the GSoC FAQ ====
===== Who will be your main organization administrator =====

Thomas B. Rücker, maintainer of the Icecast project.

===== Who will your mentors be? =====

* '''Thomas B. Rücker''' - IRC nick: ''tbr''
* '''NN''' - IRC nick:

== Questionaire for 2015 ==

=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

=== If you chose "veteran" in the checkbox, please summarize your involvement in Google Summer of Code and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ===

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were successful. One, a hardware implementation of a Theora decoder: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, implementation of OggSkeleton support in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation during past years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity to reset and be part in this year's Summer of Code with a focus on Icecast.

=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

This focus will avoiding the previous emphasis on codecs, which proved very challenging to most student participants.

=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===

Two mentors have volunteered.

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

=== What is your plan for dealing with disappearing students? ===

Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

=== What is your plan for dealing with disappearing mentors? ===

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

=== What steps will you take to encourage students to interact with your project's community before and during the program? ===

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===

=== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ===

We are a well established organization and participated in GSoC in the past.

=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===

Summer of Code Mentoring

2015-02-20T06:22:54Z

Rillian: copy remaining answers from above

== Xiph.Org Application as a mentoring organization ==

We need to apply for consideration as a mentoring organization 2015 February 9 - 20. Google lists the following questions in their [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#1._How_does_a_mentoring_organization faq]. Our work-in-progress answers are inline.

==== Describe your organization. ====

The Xiph.Org Foundation is a 501(c)(3) non-profit organization dedicated to providing open and free-to-implement multimedia technology as a foundation for an interoperable, level playing field on the Internet and other digital distribution networks. Over the past 14 years we have developed most of the major patent-free and royalty-free audio and video codecs currently in use, including Opus, Vorbis, Speex, FLAC and Theora, as well as developing the Ogg streaming format, and the Icecast streaming media server. Xiph hosted libraries like liboggplay and liboggz power the underling html5 video support in Mozilla Firefox.

==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

==== Has your organization participated in past Google Summer of Codes? ====

Yes

==== If you answered “yes” to the question above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were [http://code.google.com/soc/xiph/about.html successful]. One, a [http://code.google.com/soc/xiph/appinfo.html?csaid=5F9265EEC6FA0611 hardware implementation of a Theora decoder]: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, [http://code.google.com/soc/xiph/appinfo.html?csaid=213E2D30F095565D implementation of OggSkeleton support] in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation over the last years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity, reset and be part in this years Summer of code with a focus on Icecast, also avoiding the previous emphasis on codecs, as it proved very challenging to most student participants.

==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====

We have participated previously, in 2006, 2007, 2008 and 2009.
We applied in 2010, but weren't chosen.

==== What Open Source Initiative approved license(s) does your project use? ====

In general, we use the revised 3-clause BSD license for our libraries, to enable the widest possible uses of our formats and reference implementations.

Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.

==== What is the URL for your Ideas list? ====

http://wiki.xiph.org/Summer_of_Code_2015

==== What is the main development mailing list for your organization? ====

Icecast will be the main Xiph.org project for GSoC this year.

[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]

[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]

A complete listing of our lists is available at:

http://lists.xiph.org/mailman/listinfo/

==== What is the main IRC channel for your organization? ====

The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]

==== Who will be your backup organization administrator? ====

'''tbd'''

==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====

http://wiki.xiph.org/index.php/Summer_of_Code_Applications

==== What criteria did you use to select the mentors? Please be as specific as possible. ====

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

'''''TODO: Introduce mentors briefly.'''''
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====
Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====

We are a well established organization and participated in GSoC in the past.

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====

==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

==== Additional items not listed by the GSoC FAQ ====
===== Who will be your main organization administrator =====

Thomas B. Rücker, maintainer of the Icecast project.

===== Who will your mentors be? =====

* '''Thomas B. Rücker''' - IRC nick: ''tbr''
* '''NN''' - IRC nick:

== Questionaire for 2015 ==

=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

=== If you chose "veteran" in the checkbox, please summarize your involvement in Google Summer of Code and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ===

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were successful. One, a hardware implementation of a Theora decoder: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, implementation of OggSkeleton support in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation during past years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity to reset and be part in this year's Summer of Code with a focus on Icecast. This focus will avoiding the previous emphasis on codecs, which proved very challenging to most student participants.

=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===

Two mentors have volunteered.

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

=== What is your plan for dealing with disappearing students? ===

Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

=== What is your plan for dealing with disappearing mentors? ===

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

=== What steps will you take to encourage students to interact with your project's community before and during the program? ===

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===

=== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ===

We are a well established organization and participated in GSoC in the past.

=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===

Summer of Code Mentoring

2015-02-20T06:19:28Z

Rillian: Answers so far, copied from above with some minor modifications.

== Xiph.Org Application as a mentoring organization ==

We need to apply for consideration as a mentoring organization 2015 February 9 - 20. Google lists the following questions in their [http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page#1._How_does_a_mentoring_organization faq]. Our work-in-progress answers are inline.

==== Describe your organization. ====

The Xiph.Org Foundation is a 501(c)(3) non-profit organization dedicated to providing open and free-to-implement multimedia technology as a foundation for an interoperable, level playing field on the Internet and other digital distribution networks. Over the past 14 years we have developed most of the major patent-free and royalty-free audio and video codecs currently in use, including Opus, Vorbis, Speex, FLAC and Theora, as well as developing the Ogg streaming format, and the Icecast streaming media server. Xiph hosted libraries like liboggplay and liboggz power the underling html5 video support in Mozilla Firefox.

==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

==== Has your organization participated in past Google Summer of Codes? ====

Yes

==== If you answered “yes” to the question above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ====

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were [http://code.google.com/soc/xiph/about.html successful]. One, a [http://code.google.com/soc/xiph/appinfo.html?csaid=5F9265EEC6FA0611 hardware implementation of a Theora decoder]: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, [http://code.google.com/soc/xiph/appinfo.html?csaid=213E2D30F095565D implementation of OggSkeleton support] in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation over the last years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity, reset and be part in this years Summer of code with a focus on Icecast, also avoiding the previous emphasis on codecs, as it proved very challenging to most student participants.

==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====

We have participated previously, in 2006, 2007, 2008 and 2009.
We applied in 2010, but weren't chosen.

==== What Open Source Initiative approved license(s) does your project use? ====

In general, we use the revised 3-clause BSD license for our libraries, to enable the widest possible uses of our formats and reference implementations.

Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.

==== What is the URL for your Ideas list? ====

http://wiki.xiph.org/Summer_of_Code_2015

==== What is the main development mailing list for your organization? ====

Icecast will be the main Xiph.org project for GSoC this year.

[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]

[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]

A complete listing of our lists is available at:

http://lists.xiph.org/mailman/listinfo/

==== What is the main IRC channel for your organization? ====

The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]

==== Who will be your backup organization administrator? ====

'''tbd'''

==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====

http://wiki.xiph.org/index.php/Summer_of_Code_Applications

==== What criteria did you use to select the mentors? Please be as specific as possible. ====

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

'''''TODO: Introduce mentors briefly.'''''
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====
Our first goal will be to provide necessary support from the community such that our students do not want to suddenly vanish. We want our students to become well integrated members of the community, with ongoing contributions. That said, we're well aware of the possibility of a student disappearing.

We intend to be reasonably strict with requiring students to keep in touch - whilst we're quite happy for them to be absent for a while if they let us know in advance, we will intend to get at least twice-weekly updates from each student.

The mentors will have primary responsibility for their students, but the admins are also going to ensure that the mentors are indeed keeping track of what their students are up to. We'll ask our students to provide means for us to get in touch beyond email, where possible - phone, etc - in case we need to get in touch urgently.

==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====

Our mentors are all people who are major contributors to the Xiph projects - and have generally been contributing for many years. So, we think it's pretty unlikely that a mentor will disappear. However, we do have more mentors available than we expect to eventually have students (based on past years), so we're well able to take up the slack if a mentor becomes unavailable for any reason.

Our admins will ensure that the mentors are keeping up with the students appropriately, and should it be absolutely necessary, we will either find another appropriate mentor, or the admins will take over mentoring the students directly.

==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====

The Xiph.Org Founation conducts much of its development discussion and community-building on our IRC channels. We'll ask that the students be present there while they're working, where adequate network access makes that possible. We hope to make them feel that they're an important part of our community; that their contributions are really making a difference towards the goals of Xiph.

We intend to be open to their contributions - whilst we're aware that initially their work may not be of a quality sufficient to go into our core codebase immediately, we'll give them write access to our repositories to work on a branch. We'll ask them to be open in discussing and designing their contributions on IRC and our mailing lists. Our application template welcomes them to come and ask us questions when they're trying to write up their application. We hope that some, or even all, of the students will continue to be part of the Xiph community after SoC concludes. For those students who have not previously contributed to open source software, we'll teach them about how important community building is for the ongoing health of such projects.

==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====

We are a well established organization and participated in GSoC in the past.

==== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ====

==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====

We hope that the mentoring process and the experiences they have as part of GSoC will make the students interested in remaining part of Xiph, continuing development on the software they've been working on, and perhaps nurturing their patches towards inclusion in an actual release.

A very important part of GSoC is for us to make them active members of the community, in particular on the irc channels and the mailing lists. Past experience tells that once they have become part of that community, they will stick around for longer.

We will encourage them not to consider this just "a summer job", but as being part of a real community — and doing something that is both interesting, and useful to the wider world.

==== Additional items not listed by the GSoC FAQ ====
===== Who will be your main organization administrator =====

Thomas B. Rücker, maintainer of the Icecast project.

===== Who will your mentors be? =====

* '''Thomas B. Rücker''' - IRC nick: ''tbr''
* '''NN''' - IRC nick:

== Questionaire for 2015 ==

=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===

The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.

=== If you chose "veteran" in the checkbox, please summarize your involvement in Google Summer of Code and the successes and challenges of your participation. Please also list your pass/fail rate for each year. ===

In 2006, we were granted funding for 6 slots. One we weren't able to fill because our chosen students picked or were assigned to other projects.

Two were successful. One, a hardware implementation of a Theora decoder: this project produced HDL implementation of the major decoder components, to be used with a general purpose CPU, such as the open source LEON sparc implementation. Real time playback of SD content was demonstrated using these components in combination with the proprietary Nagios CPU design. Two, implementation of OggSkeleton support in various tools. We have maintained contact with the two successful students since the program finished. One has continued to contribute code outside the GSoC term, continuing related work.

The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.

In 2007, we were given 2 project slots. One was an extension of the hardware decoder effort from last year. The other was helping to do R&D on Xiph's next-generation audio codec, Ghost. Both were marginally successful — the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program.

We participated in 2008 and 2009. Sadly at this time we're unable to locate a report about both years and must assume that both were unsuccessful.

We enjoyed our participation during past years. It provided needed external input, energizing our project and improving our connections to the rest of the open source community. We'd like to take the opportunity to reset and be part in this year's Summer of Code with a focus on Icecast. This focus will avoiding the previous emphasis on codecs, which proved very challenging to most student participants.

=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===

We believe that the Xiph.Org Foundation and specifically the Icecast Project has a wide-ranging set of projects that are both challenging and educational for students. Furthermore, they are important/useful goals for the wider technology community, and especially users of open source software.

We believe that Xiph's mandate to develop multimedia standards and software is an important one, but as a small non-profit with no official staff we—of course—have limited resources. We hope that the results of GSoC will include the direct benefit of new software development, but also help grow the number of active participants in a long-term manner. Most of our core developers started as students, but have since moved on from their student days. Attracting and retaining students is essential to the health and sustainability of our project and is an important goal for all of us.

The Icecast multimedia streaming project has recently regained development momentum, but we are looking to involve more people, especially students. This should help us sustain momentum and strengthen our team.

=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===

Two mentors have volunteered.

We selected our mentors from the 'core' developers and contributors within Xiph. Mentors were selected based on how well they know the code area they're volunteering to mentor, how long they've been part of Xiph, how well they interact with others (particularly in terms of building community around our projects).

The majority of the mentors we've selected are core developers on the various Xiph sub-projects that they've volunteered to mentor for. They have been contributing to the Xiph.Org Foundation for at least several years, and have shown a persistent interest both in the software we develop, and in helping to create a community around it. We have also made sure that each mentor has sufficient time available to adequately mentor their student(s).

=== What is your plan for dealing with disappearing students? ===

=== What is your plan for dealing with disappearing mentors? ===

=== What steps will you take to encourage students to interact with your project's community before and during the program? ===

=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===

=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===

=== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ===

=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===

Summer of Code Mentoring

2015-02-20T06:17:49Z

Rillian: Dump questionaire from the 2015 organization application

How to help

2015-02-11T21:58:11Z

Rillian: Move OggDSF downpage. This is no longer an active project

__NOTOC__
This page is intended to collect ideas and areas where new participants can contribute to Xiph.org initiatives.
Because this is an open wiki not all of these points have been reviewed with core Xiph developers. It is always best to coordinate your efforts on the relevant Xiph mailing lists and IRC channels.

One of the best ways people can contribute is by using the tools and formats. This accomplishes two primary goals:
#By providing materials in free formats you help lower the barriers to adoption for others
#By using the tools you will discover problems which you can report contributing to further development and refinement

Must of our organizational discussion happens over irc on the freenode.net network. See project-specific channels below,
or join #xiph on irc.freenode.net for general information.

==Software outreach==
Xiph.org software often reaches users via other software. E.g. Few people run libtheora by itself, many people use libtheora through other tools like VLC, Firefox, or gstreamer. These tools are maintained by other projects but the reliability and robustness of the free format support in these applications is critical to the public's ability to use Xiph.org formats.

Relevant contribution areas:
#Testing, e.g. [[TheoraTestsuite]] and reporting bugs into the relevant bug trackers
#Cross porting features
#Updating tools to support the latest features in the Xiph.org implementations (e.g. two-pass encoding for video tools)

==Theora specific activities==
Places to discuss development: Theora mailing list; #theora on irc.freenode.net

*Identifying videos where 1.1 or 1.2-development (ptalarbvorm) produce significantly worse results than prior versions. (These case is important compared to "works worse than some random format" because the differences are more likely to be actionable rather than just chance consequences related to differences in the encoders overall behaviour)

*Decoder assembly optimization for additional platforms (MIPS64; PPC)
**Skills required: optimization and development experience on the relevant platform.

*Decoder general performance improvements
**Skills required: C language; Use of a profiler. Optionally: SIMD assembly on relevant platforms.

==Vorbis specific activities==
Places to discuss development: Vorbis mailing list; #vorbis on irc.freenode.net

*Identifying test samples where Vorbis encodings at very high quality are not completely transparent under careful listening tests.
*Identifying test cases that exemplify the improvements in the current AoTuV development. (Helps with AoTuV merging)
*Identifying test samples where Vorbis performs worse than other formats.

==Skeleton specific activities==
Places to discuss development: Theora mailing list; #theora on irc.freenode.net

==Liboggz specific activities==
Places to discuss development: Theora mailing list; #theora on irc.freenode.net

==Cortado specific activities==
Places to discuss development: Theora mailing list; #theora on irc.freenode.net

Cortado is contains Java implementation of Vorbis/Theora/Kate/Ogg and an applet that allows playback of these formats on the web. It is the most popular fallback for HTML5 Ogg video, allowing users on legacy browsers (as old as Netscape 4) to play modern web video.
* See the cortado todo: [[Cortado/todo]]

==Flash port of Theora==
There are several workable implementations of Vorbis for the flash virtual machine. An implementation of Theora would allow the creation of a flash applet which plays Ogg video. One possible tool for this would be Adobe Alchemy, a C to Flash compiler which can be used to compile libtheora for flash. Beyond the basic codec porting work there is significant effort required building a player infrastructure around them because the built-in flash video infrastructure are not available for user implemented codecs (unlike silverlight). This initiative is primarily hindered by the surprising lack of overlap between flash developers and people who care about unencumbered formats.

==Additional tools work==
*Build and refine fall-back tools for HTML5 video based on Cortado, Flash Vorbis, and the upcoming Silverlight applet support. Many existing fallback tools require users to adopt H.264, such tools are valuable for media providers who are willing and able to distribute H.264 but they are not useful for ones who are not, and they are not tools that Xiph can really stand behind.

==OggDSF specific activities==
Directshow is the windows video codec API, OggDSF provides support for Vorbis/Theora/Speex/Flac and Ogg in directshow.

Places to discuss development: Theora mailing list; #theora on irc.freenode.net

*Testing. Much of the Xiph.org community are run various unix-like operating systems. While OggDSF is widely used, it isn't frequently used by much of the more experienced Xiph.org community and hasn't has sufficient scrutiny.

==PR and organizational matters==
*Participate in external promotional activities such as [http://www.fsf.org/resources/formats/playogg PlayOgg!]
*[http://videoonwikipedia.org Contribute] to Wikipedia's video collection
*Locate media coverage regarding free formats and related areas and share it with the the mailing lists
*Encourage additional media distributors to support HTML5 with Theora

==Internet outreach==
* Encourage places using poor tools (e.g. ffvorbis encoder) to switch to better software.
* Encourage adoption of Theora video for html5 and theora based fallbacks

How to help

2015-02-11T21:57:30Z

Rillian: Mention #xiph at the top of the page.

__NOTOC__
This page is intended to collect ideas and areas where new participants can contribute to Xiph.org initiatives.
Because this is an open wiki not all of these points have been reviewed with core Xiph developers. It is always best to coordinate your efforts on the relevant Xiph mailing lists and IRC channels.

One of the best ways people can contribute is by using the tools and formats. This accomplishes two primary goals:
#By providing materials in free formats you help lower the barriers to adoption for others
#By using the tools you will discover problems which you can report contributing to further development and refinement

Must of our organizational discussion happens over irc on the freenode.net network. See project-specific channels below,
or join #xiph on irc.freenode.net for general information.

==OggDSF specific activities==
Directshow is the windows video codec API, OggDSF provides support for Vorbis/Theora/Speex/Flac and Ogg in directshow.

Places to discuss development: Theora mailing list; #theora on irc.freenode.net

*Testing. Much of the Xiph.org community are run various unix-like operating systems. While OggDSF is widely used, it isn't frequently used by much of the more experienced Xiph.org community and hasn't has sufficient scrutiny.

==Software outreach==
Xiph.org software often reaches users via other software. E.g. Few people run libtheora by itself, many people use libtheora through other tools like VLC, Firefox, or gstreamer. These tools are maintained by other projects but the reliability and robustness of the free format support in these applications is critical to the public's ability to use Xiph.org formats.

Relevant contribution areas:
#Testing, e.g. [[TheoraTestsuite]] and reporting bugs into the relevant bug trackers
#Cross porting features
#Updating tools to support the latest features in the Xiph.org implementations (e.g. two-pass encoding for video tools)

==Theora specific activities==
Places to discuss development: Theora mailing list; #theora on irc.freenode.net

*Identifying videos where 1.1 or 1.2-development (ptalarbvorm) produce significantly worse results than prior versions. (These case is important compared to "works worse than some random format" because the differences are more likely to be actionable rather than just chance consequences related to differences in the encoders overall behaviour)

*Decoder assembly optimization for additional platforms (MIPS64; PPC)
**Skills required: optimization and development experience on the relevant platform.

*Decoder general performance improvements
**Skills required: C language; Use of a profiler. Optionally: SIMD assembly on relevant platforms.

==Vorbis specific activities==
Places to discuss development: Vorbis mailing list; #vorbis on irc.freenode.net

*Identifying test samples where Vorbis encodings at very high quality are not completely transparent under careful listening tests.
*Identifying test cases that exemplify the improvements in the current AoTuV development. (Helps with AoTuV merging)
*Identifying test samples where Vorbis performs worse than other formats.

==Skeleton specific activities==
Places to discuss development: Theora mailing list; #theora on irc.freenode.net

==Liboggz specific activities==
Places to discuss development: Theora mailing list; #theora on irc.freenode.net

==Cortado specific activities==
Places to discuss development: Theora mailing list; #theora on irc.freenode.net

Cortado is contains Java implementation of Vorbis/Theora/Kate/Ogg and an applet that allows playback of these formats on the web. It is the most popular fallback for HTML5 Ogg video, allowing users on legacy browsers (as old as Netscape 4) to play modern web video.
* See the cortado todo: [[Cortado/todo]]

==Flash port of Theora==
There are several workable implementations of Vorbis for the flash virtual machine. An implementation of Theora would allow the creation of a flash applet which plays Ogg video. One possible tool for this would be Adobe Alchemy, a C to Flash compiler which can be used to compile libtheora for flash. Beyond the basic codec porting work there is significant effort required building a player infrastructure around them because the built-in flash video infrastructure are not available for user implemented codecs (unlike silverlight). This initiative is primarily hindered by the surprising lack of overlap between flash developers and people who care about unencumbered formats.

==Additional tools work==
*Build and refine fall-back tools for HTML5 video based on Cortado, Flash Vorbis, and the upcoming Silverlight applet support. Many existing fallback tools require users to adopt H.264, such tools are valuable for media providers who are willing and able to distribute H.264 but they are not useful for ones who are not, and they are not tools that Xiph can really stand behind.

==PR and organizational matters==
*Participate in external promotional activities such as [http://www.fsf.org/resources/formats/playogg PlayOgg!]
*[http://videoonwikipedia.org Contribute] to Wikipedia's video collection
*Locate media coverage regarding free formats and related areas and share it with the the mailing lists
*Encourage additional media distributors to support HTML5 with Theora

==Internet outreach==
* Encourage places using poor tools (e.g. ffvorbis encoder) to switch to better software.
* Encourage adoption of Theora video for html5 and theora based fallbacks

MIME Types and File Extensions

2015-01-08T22:32:43Z

Rillian: Add opus filetype.

STATUS: Work on RFCs and tools is in process to reflect these policies. More details are [http://wiki.xiph.org/index.php/MIMETypesCodecs here], which also include a specification of the codecs parameter of the MIME tyes. Use the correct file extensions straight away.

DISCLAIMER: currently, application/ogg, video/ogg, audio/ogg and audio/vorbis are registered MIME types. Registration for the others will be undertaken. During this process, the "x-" versions of these unregistered MIME types may be used.

IMPLEMENTATION recommendations and patches: see [[MIME-Migration]].

== .ogg - audio/ogg ==

* Ogg Vorbis I Profile
* .ogg applies now for Vorbis I files only
* .ogg has more recently also been used for Ogg FLAC and for Theora, too — these uses are deprecated now in favor of .oga and .ogv respectively
* has been defined in RFC 3534 http://www.ietf.org/rfc/rfc3534.txt for application/ogg, so rfc 3534 will be re-defined

RATIONALE: .ogg has traditionally been used for Vorbis I files, in particular in HW players, hence it is kept for backwards-compatibility

== .ogv - video/ogg ==

* Ogg Video Profile (a/v in Ogg container)
* apps supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams
* covers e.g. [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg
* This list is not exhaustive (for example, [[Dirac]] + FLAC is acceptable too)
* SHOULD contain a Skeleton track and/or MAY contain a CMML logical bitstream.

== .opus - audio/ogg ==

* Ogg Opus profile
* Defined by https://tools.ietf.org/html/draft-ietf-codec-oggopus

== .oga - audio/ogg ==

* Ogg Audio Profile (audio in Ogg container)
* Applications supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams
* Covers Ogg [[FLAC]], [[Opus]], [[Ghost]], and [[OggPCM]]
* Although they share the same MIME type, Vorbis and Speex use different file extensions.
* SHOULD contain a Skeleton logical bitstream.
* Vorbis and Speex may use .oga, but it is not the prefered method of distributing these files because of backwards-compatibility issues.

== .ogx - application/ogg ==

* Ogg Multiplex Profile (anything in [[Ogg]])
* can contain any logical bitstreams multiplexed together in an ogg container
* will replace the .ogg extension from RFC 3534 http://www.ietf.org/rfc/rfc3534.txt
* random multitrack files MUST contain a [[Skeleton]] track to identify all containing logical bitstreams
* apps that identify a logical bitstream which they cannot decode SHOULD ignore it but MAY still decode the ones they can
* thus, e.g. an annodex file can gracefully degrade to .ogx if an app cannot decode [[CMML]] and/or [[Skeleton]]
* USE: application/ogg has been registered, so can be used immediately

== .spx - audio/ogg ==

* Ogg Speex Profile
* .spx has traditionally been used for Speex files within Ogg and should be considered for backwards-compatibility

== .flac - audio/flac ==

* FLAC in native encapsulation format

== .anx - application/annodex ==

* Profile for multiplexed Ogg that includes a skeleton track and at least one CMML logical bitstream
* apps that identify a logical bitstream which they cannot decode SHOULD ignore it but MAY still decode the ones they can
* apps that come across an annodex file and cannot decode CMML and/or Skeleton, but can deal with the others SHOULD gracefully degrade by ignoring these

== .axa - audio/annodex ==

* Profile for audio in Annodex
* covers e.g. [[Vorbis]], [[Speex]], [[FLAC]], [[Opus]], [[Ghost]], [[OggPCM]] inside Ogg with Skeleton and CMML

== .axv - video/annodex ==

* Profile for video in Annodex
* covers e.g. [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg with Skeleton and CMML

== .xspf - application/xspf+xml ==

* Profile for XSPF
* Covers [[XSPF]], while being used through XML
* Does not cover [[JSPF]], which is XSPF but on JSON

== Ogg Kate files - application/kate ==

* Binary representation of Kate encapsulated in Ogg
* may have a skeleton
* can be used to identify the mime type of the track itself (e.g. in skeleton)
* uses .ogx extension when in a file by itself
* is subdued by the dominant mime type if in a audio or video file to become audio/ogg or video/ogg

== Codec MIME types ==

Codecs need their own MIME types for streaming in RTP and to be used in multitrack ogg files using skeleton:

* audio/vorbis for Vorbis without container
* video/theora for Theora without container
* audio/speex for Speex without container
* audio/flac for FLAC without and in native container
* audio/opus for Opus without container
* text/cmml for CMML without container
* application/kate for the textual representation of Kate (.kate files)

MIME Types and File Extensions

2015-01-08T22:31:11Z

Rillian: Put more relevant extensions at the top

STATUS: Work on RFCs and tools is in process to reflect these policies. More details are [http://wiki.xiph.org/index.php/MIMETypesCodecs here], which also include a specification of the codecs parameter of the MIME tyes. Use the correct file extensions straight away.

DISCLAIMER: currently, application/ogg, video/ogg, audio/ogg and audio/vorbis are registered MIME types. Registration for the others will be undertaken. During this process, the "x-" versions of these unregistered MIME types may be used.

IMPLEMENTATION recommendations and patches: see [[MIME-Migration]].

== .ogg - audio/ogg ==

* Ogg Vorbis I Profile
* .ogg applies now for Vorbis I files only
* .ogg has more recently also been used for Ogg FLAC and for Theora, too — these uses are deprecated now in favor of .oga and .ogv respectively
* has been defined in RFC 3534 http://www.ietf.org/rfc/rfc3534.txt for application/ogg, so rfc 3534 will be re-defined

RATIONALE: .ogg has traditionally been used for Vorbis I files, in particular in HW players, hence it is kept for backwards-compatibility

== .ogv - video/ogg ==

* Ogg Video Profile (a/v in Ogg container)
* apps supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams
* covers e.g. [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg
* This list is not exhaustive (for example, [[Dirac]] + FLAC is acceptable too)
* SHOULD contain a Skeleton track and/or MAY contain a CMML logical bitstream.

== .oga - audio/ogg ==

* Ogg Audio Profile (audio in Ogg container)
* Applications supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams
* Covers Ogg [[FLAC]], [[Opus]], [[Ghost]], and [[OggPCM]]
* Although they share the same MIME type, Vorbis and Speex use different file extensions.
* SHOULD contain a Skeleton logical bitstream.
* Vorbis and Speex may use .oga, but it is not the prefered method of distributing these files because of backwards-compatibility issues.

== .ogx - application/ogg ==

* Ogg Multiplex Profile (anything in [[Ogg]])
* can contain any logical bitstreams multiplexed together in an ogg container
* will replace the .ogg extension from RFC 3534 http://www.ietf.org/rfc/rfc3534.txt
* random multitrack files MUST contain a [[Skeleton]] track to identify all containing logical bitstreams
* apps that identify a logical bitstream which they cannot decode SHOULD ignore it but MAY still decode the ones they can
* thus, e.g. an annodex file can gracefully degrade to .ogx if an app cannot decode [[CMML]] and/or [[Skeleton]]
* USE: application/ogg has been registered, so can be used immediately

== .spx - audio/ogg ==

* Ogg Speex Profile
* .spx has traditionally been used for Speex files within Ogg and should be considered for backwards-compatibility

== .flac - audio/flac ==

* FLAC in native encapsulation format

== .anx - application/annodex ==

* Profile for multiplexed Ogg that includes a skeleton track and at least one CMML logical bitstream
* apps that identify a logical bitstream which they cannot decode SHOULD ignore it but MAY still decode the ones they can
* apps that come across an annodex file and cannot decode CMML and/or Skeleton, but can deal with the others SHOULD gracefully degrade by ignoring these

== .axa - audio/annodex ==

* Profile for audio in Annodex
* covers e.g. [[Vorbis]], [[Speex]], [[FLAC]], [[Opus]], [[Ghost]], [[OggPCM]] inside Ogg with Skeleton and CMML

== .axv - video/annodex ==

* Profile for video in Annodex
* covers e.g. [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg with Skeleton and CMML

== .xspf - application/xspf+xml ==

* Profile for XSPF
* Covers [[XSPF]], while being used through XML
* Does not cover [[JSPF]], which is XSPF but on JSON

== Ogg Kate files - application/kate ==

* Binary representation of Kate encapsulated in Ogg
* may have a skeleton
* can be used to identify the mime type of the track itself (e.g. in skeleton)
* uses .ogx extension when in a file by itself
* is subdued by the dominant mime type if in a audio or video file to become audio/ogg or video/ogg

== Codec MIME types ==

Codecs need their own MIME types for streaming in RTP and to be used in multitrack ogg files using skeleton:

* audio/vorbis for Vorbis without container
* video/theora for Theora without container
* audio/speex for Speex without container
* audio/flac for FLAC without and in native container
* audio/opus for Opus without container
* text/cmml for CMML without container
* application/kate for the textual representation of Kate (.kate files)

Mp4Opus

2014-09-23T19:09:46Z

Rillian: Link to Paranoialmaniac's draft

{{draft}}
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.

[http://wiki.multimedia.cx/index.php?title=MP4 MP4] already has support for declaring encoder delay and pre-roll.

For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.

For delay, Daemon404 suggested "whatever l-smash maps encoder delay to."
yusuke says, "ISO and Apple recommend the use of edit list for removing priming samples from the presentation." libavformat's demuxer supports *one* edit list entry.

See also [http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html Paranoialmaniac's draft].

There's some work on codec-independent channel mapping, downmix and dynamic range control as part of [http://mpeg.chiariglione.org/standards/mpeg-4/iso-base-media-file-format/text-isoiec-14496-122012-pdam-4-enhanced-audio-support ISO 14496-12 Amd4] We might be able use some of that, but it doesn't support the Opus case of needing to indicated which streams are coupled pairs. We'll still need to define our own extension for this.

Question: Better to reuse the channel mapping header entirely, or just report the coupled stream count and use the downmix table to do the mapping?

Possible registration process, send an email to http://mp4ra.org/request.html. Possible registrar is 'Opus'.

Internally everything is resampled at 48000, this is always output by the decoder, floating point numbers. But the original sample rate is stored so that the decoder can act upon it. Atom AudioSampleEntry will have 48 and the original one will be stored in the codec's one.

'''Global Header'''

''AudioRollRecoveryEntry'' - shall have a value of 3840 (80ms * 48k)

''AudioSampleEntry'' - hardcoded at 16fp

''descriptor'' - same as ogg rather than as ts, to keep things simple

''channel count'' - already included
''pre skip'' - already included

''Gain'' - volume atom? unused in practice - oggheader - not in ts (TODO?)
when you decode samples you're supposed to multiply against this value, so that decoder can apply post volume
Reusing the one in ogg.

''mapping family'' (with vorbis mapping)
- mono/stereo no channel config
- specify # channel
- map to the # ouput

audio channel layout https://developer.apple.com/library/mac/documentation/musicaudio/reference/CoreAudioDataTypesRef/Reference/reference.html - too complex
plug it from ogg and put it in our custom atom

'''Things to put in custom atom'''
- input sr
- output gain
- channel mappaing
- channel count (for backup)

'''Opus''' is the name of the atom, like in TS

what about album art? quicktime/mp4/mp3

Mp4Opus

2014-09-23T19:07:45Z

Rillian: One edit list entry supports both start and end trim.

{{draft}}
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.

[http://wiki.multimedia.cx/index.php?title=MP4 MP4] already has support for declaring encoder delay and pre-roll.

For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.

For delay, Daemon404 suggested "whatever l-smash maps encoder delay to."
yusuke says, "ISO and Apple recommend the use of edit list for removing priming samples from the presentation." libavformat's demuxer supports *one* edit list entry.

There's some work on codec-independent channel mapping, downmix and dynamic range control as part of [http://mpeg.chiariglione.org/standards/mpeg-4/iso-base-media-file-format/text-isoiec-14496-122012-pdam-4-enhanced-audio-support ISO 14496-12 Amd4] We might be able use some of that, but it doesn't support the Opus case of needing to indicated which streams are coupled pairs. We'll still need to define our own extension for this.

Question: Better to reuse the channel mapping header entirely, or just report the coupled stream count and use the downmix table to do the mapping?

Possible registration process, send an email to http://mp4ra.org/request.html. Possible registrar is 'Opus'.

Internally everything is resampled at 48000, this is always output by the decoder, floating point numbers. But the original sample rate is stored so that the decoder can act upon it. Atom AudioSampleEntry will have 48 and the original one will be stored in the codec's one.

'''Global Header'''

''AudioRollRecoveryEntry'' - shall have a value of 3840 (80ms * 48k)

''AudioSampleEntry'' - hardcoded at 16fp

''descriptor'' - same as ogg rather than as ts, to keep things simple

''channel count'' - already included
''pre skip'' - already included

''Gain'' - volume atom? unused in practice - oggheader - not in ts (TODO?)
when you decode samples you're supposed to multiply against this value, so that decoder can apply post volume
Reusing the one in ogg.

''mapping family'' (with vorbis mapping)
- mono/stereo no channel config
- specify # channel
- map to the # ouput

audio channel layout https://developer.apple.com/library/mac/documentation/musicaudio/reference/CoreAudioDataTypesRef/Reference/reference.html - too complex
plug it from ogg and put it in our custom atom

'''Things to put in custom atom'''
- input sr
- output gain
- channel mappaing
- channel count (for backup)

'''Opus''' is the name of the atom, like in TS

what about album art? quicktime/mp4/mp3

Mp4Opus

2014-07-09T17:45:33Z

Rillian: Mention edit lists for pre-skip

{{draft}}
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.

MP4 already has support for declaring encoder delay and pre-roll.

For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.

For delay, Daemon404 suggested "whatever l-smash maps encoder delay to."
yusuke says, "ISO and Apple recommend the use of edit list for removing priming samples from the presentation." libavformat's demuxer supports *one* edit list.

There's some work on codec-independent channel mapping, downmix and dynamic range control as part of [http://mpeg.chiariglione.org/standards/mpeg-4/iso-base-media-file-format/text-isoiec-14496-122012-pdam-4-enhanced-audio-support ISO 14496-12 Amd4] We might be able use some of that, but it doesn't support the Opus case of needing to indicated which streams are coupled pairs. We'll still need to define our own extension for this.

Question: Better to reuse the channel mapping header entirely, or just report the coupled stream count and use the downmix table to do the mapping?

Mp4Opus

2014-07-09T17:12:43Z

Rillian: fix link

{{draft}}
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.

MP4 already has support for declaring encoder delay and pre-roll.

For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.

There's some work on codec-independent channel mapping, downmix and dynamic range control as part of [http://mpeg.chiariglione.org/standards/mpeg-4/iso-base-media-file-format/text-isoiec-14496-122012-pdam-4-enhanced-audio-support ISO 14496-12 Amd4] We might be able use some of that, but it doesn't support the Opus case of needing to indicated which streams are coupled pairs. We'll still need to define our own extension for this.

Question: Better to reuse the channel mapping header entirely, or just report the coupled stream count and use the downmix table to do the mapping?

Mp4Opus

2014-07-09T17:11:51Z

Rillian: Things which have come up so far

{{draft}}
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.

MP4 already has support for declaring encoder delay and pre-roll.

For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.

There's some work on codec-independent channel mapping, downmix and dynamic range control as part of [[ISO 14496-12 Amd4 http://mpeg.chiariglione.org/standards/mpeg-4/iso-base-media-file-format/text-isoiec-14496-122012-pdam-4-enhanced-audio-support]] We might be able use some of that, but it doesn't support the Opus case of needing to indicated which streams are coupled pairs. We'll still need to define our own extension for this.

Question: Better to reuse the channel mapping header entirely, or just report the coupled stream count and use the downmix table to do the mapping?

Mp4Opus

2014-07-09T16:42:41Z

Rillian: Start a page collecting ideas for Opus in MP4

{{draft}}
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.

Daala Quickstart

2014-07-04T18:52:03Z

Rillian: /* Mac OS X */ Xcode should include git

= Getting Started =

This is a simple guide to getting the code and encoding a simple video.

== Installation ==

=== Pre-requisites ===
* Standard build tools (autoconf, automake v1.11 or later, libtool, and a C compiler)
* git
* libogg (v1.3 or later)
* libpng
* libjpeg
* libcheck (v0.9.8 or later, can be skipped if you pass --disable-unit-tests to ./configure)
* libsdl (can by skipped if you pass --disable-player to ./configure)

Instructions for installing these packages are OS-specific (feel free to contribute some here, especially if you tried installing these somewhere and ran into difficulties; you will likely save other people some pain). If you have a package manager that has separate -dev versions with the public headers, make sure you install those in addition to the actual libraries.

==== Mac OS X ====
Install Apple's command line developer tools. E.g. install [https://developer.apple.com/xcode/ Xcode] from the App Store and select 'Command Line Tools' from the Preferences::Downloads panel, or download and install the pkg directly from [https://developer.apple.com/downloads/ developer.apple.com].

Install [http://brew.sh/ Homebrew]

Run the following command to install dependencies:
brew install autoconf automake libtool libogg libpng libjpeg check sdl

=== Installation Procedure ===

Just run these commands:

git clone https://git.xiph.org/daala.git
cd daala
./autogen.sh
./configure
make

Note that the git clone can take several minutes to complete.

And optionally

make tools

Make sure you run the git clone operation on the same machine where you intend to use the code. Checking out a copy on Windows and then trying to use it on Linux will not work, as executable permissions and line-endings will not be set properly.

== Encoding a Video ==

If you do not have one, get a sample video or two in .y4m format from [https://media.xiph.org/video/derf/ media.xiph.org]. We also maintain a set of still-image collections in .y4m format:
* [https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz Subset 1] (50 images, small training set)
* [https://people.xiph.org/~tterribe/daala/subset2-y4m.tar.gz Subset 2] (1000 images, large training set)
* [https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz Subset 3] (50 images, small testing set)
* [https://people.xiph.org/~tterribe/daala/subset4-y4m.tar.gz Subset 4] (1000 images, large testing set)

Encode the video:

./examples/encoder_example -v 30 -k 256 video.y4m -o video.ogv

where
* video.y4m is the input video you want to encode,
* video.ogv is the name of the encoded video file to output,
* -v specifies the quality (currently from 0 to 511, where 0 is lossless), and
* -k specifies the maximum keyframe interval (this is currently 1 by default, which makes every frame a keyframe).

== Decoding a Video ==

Play the video:

./examples/player_example -p video.ogv

The -p option starts the player paused. Run

./examples/player_example --help

for information on the controls available while playing.

If you want to use a different player, you can decode the video back to .y4m with

./examples/dump_video video.ogv -o decoded_video.y4m

Many other players can play back these .y4m files, and other tools can convert them to various other formats.

== Using PNG Images ==

To encode a series of images:

make tools
./tools/png2y4m video%05d.png -o video.y4m

where %05d means your input images are named video00000.png, video00001.png, etc. You can leave out the %05d tag if you only want to convert a single image (which does not need to be numbered).

To convert a y4m back to PNGs:

./tools/y4m2png video.y4m -o video%05d.png

If you are converting a .y4m file that only contains a single frame (e.g., from one of the still-image subsets linked above), you can leave out the %05d tag. Conversion from PNG to Y4M uses the Rec 709 matrix with video levels, a box filter for chroma subsampling, and a triangular dither. Conversion back from Y4M to PNG uses the same matrix, levels, and box filter, but does not dither.

Daala Quickstart

2014-07-04T18:51:12Z

Rillian: /* Mac OS X */ Mention Xcode

= Getting Started =

This is a simple guide to getting the code and encoding a simple video.

== Installation ==

=== Pre-requisites ===
* Standard build tools (autoconf, automake v1.11 or later, libtool, and a C compiler)
* git
* libogg (v1.3 or later)
* libpng
* libjpeg
* libcheck (v0.9.8 or later, can be skipped if you pass --disable-unit-tests to ./configure)
* libsdl (can by skipped if you pass --disable-player to ./configure)

Instructions for installing these packages are OS-specific (feel free to contribute some here, especially if you tried installing these somewhere and ran into difficulties; you will likely save other people some pain). If you have a package manager that has separate -dev versions with the public headers, make sure you install those in addition to the actual libraries.

==== Mac OS X ====
Install Apple's command line developer tools. E.g. install [https://developer.apple.com/xcode/ Xcode] from the App Store and select 'Command Line Tools' from the Preferences::Downloads panel, or download and install the pkg directly from [https://developer.apple.com/downloads/ developer.apple.com].

Install [http://brew.sh/ Homebrew]

Run the following command to install dependencies:
brew install autoconf automake libtool git libogg libpng libjpeg check sdl

=== Installation Procedure ===

Just run these commands:

git clone https://git.xiph.org/daala.git
cd daala
./autogen.sh
./configure
make

Note that the git clone can take several minutes to complete.

And optionally

make tools

Make sure you run the git clone operation on the same machine where you intend to use the code. Checking out a copy on Windows and then trying to use it on Linux will not work, as executable permissions and line-endings will not be set properly.

== Encoding a Video ==

If you do not have one, get a sample video or two in .y4m format from [https://media.xiph.org/video/derf/ media.xiph.org]. We also maintain a set of still-image collections in .y4m format:
* [https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz Subset 1] (50 images, small training set)
* [https://people.xiph.org/~tterribe/daala/subset2-y4m.tar.gz Subset 2] (1000 images, large training set)
* [https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz Subset 3] (50 images, small testing set)
* [https://people.xiph.org/~tterribe/daala/subset4-y4m.tar.gz Subset 4] (1000 images, large testing set)

Encode the video:

./examples/encoder_example -v 30 -k 256 video.y4m -o video.ogv

where
* video.y4m is the input video you want to encode,
* video.ogv is the name of the encoded video file to output,
* -v specifies the quality (currently from 0 to 511, where 0 is lossless), and
* -k specifies the maximum keyframe interval (this is currently 1 by default, which makes every frame a keyframe).

== Decoding a Video ==

Play the video:

./examples/player_example -p video.ogv

The -p option starts the player paused. Run

./examples/player_example --help

for information on the controls available while playing.

If you want to use a different player, you can decode the video back to .y4m with

./examples/dump_video video.ogv -o decoded_video.y4m

Many other players can play back these .y4m files, and other tools can convert them to various other formats.

== Using PNG Images ==

To encode a series of images:

make tools
./tools/png2y4m video%05d.png -o video.y4m

where %05d means your input images are named video00000.png, video00001.png, etc. You can leave out the %05d tag if you only want to convert a single image (which does not need to be numbered).

To convert a y4m back to PNGs:

./tools/y4m2png video.y4m -o video%05d.png

If you are converting a .y4m file that only contains a single frame (e.g., from one of the still-image subsets linked above), you can leave out the %05d tag. Conversion from PNG to Y4M uses the Rec 709 matrix with video levels, a box filter for chroma subsampling, and a triangular dither. Conversion back from Y4M to PNG uses the same matrix, levels, and box filter, but does not dither.

Daala Quickstart

2014-06-02T23:16:51Z

Rillian: /* Installation Procedure */ Mention our git is slow.

= Getting Started =

This is a simple guide to getting the code and encoding a simple video.

== Installation ==

=== Pre-requisites ===
* Standard build tools (autoconf, automake v1.11 or later, libtool, and a C compiler)
* git
* libogg (v1.3 or later)
* libpng
* libjpeg
* libcheck (v0.9.8 or later, can be skipped if you pass --disable-unit-tests to ./configure)
* libsdl (can by skipped if you pass --disable-player to ./configure)

Instructions for installing these packages are OS-specific (feel free to contribute some here, especially if you tried installing these somewhere and ran into difficulties; you will likely save other people some pain). If you have a package manager that has separate -dev versions with the public headers, make sure you install those in addition to the actual libraries.

=== Installation Procedure ===

Just run these commands:

git clone https://git.xiph.org/daala.git
cd daala
./autogen.sh
./configure
make

Note that the git clone can take several minutes to complete.

And optionally

make tools

Make sure you run the git clone operation on the same machine where you intend to use the code. Checking out a copy on Windows and then trying to use it on Linux will not work, as executable permissions and line-endings will not be set properly.

== Encoding a Video ==

If you do not have one, get a sample video or two in .y4m format from [https://media.xiph.org/video/derf/ media.xiph.org]. We also maintain a set of still-image collections in .y4m format:
* [https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz Subset 1] (50 images, small training set)
* [https://people.xiph.org/~tterribe/daala/subset2-y4m.tar.gz Subset 2] (1000 images, large training set)
* [https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz Subset 3] (50 images, small testing set)
* [https://people.xiph.org/~tterribe/daala/subset4-y4m.tar.gz Subset 4] (1000 images, large testing set)

Encode the video:

./examples/encoder_example -v 30 -k 256 video.y4m -o video.ogv

where
* video.y4m is the input video you want to encode,
* video.ogv is the name of the encoded video file to output,
* -v specifies the quality (currently from 0 to 511, where 0 is lossless), and
* -k specifies the maximum keyframe interval (this is currently 1 by default, which makes every frame a keyframe).

== Decoding a Video ==

Play the video:

./examples/player_example -p video.ogv

The -p option starts the player paused. Run

./examples/player_example --help

for information on the controls available while playing.

If you want to use a different player, you can decode the video back to .y4m with

./examples/dump_video video.ogv -o decoded_video.y4m

Many other players can play back these .y4m files, and other tools can convert them to various other formats.

== Using PNG Images ==

To encode a series of images:

make tools
./tools/png2y4m video%05d.png -o video.y4m

where %05d means your input images are named video00000.png, video00001.png, etc. You can leave out the %05d tag if you only want to convert a single image (which does not need to be numbered).

To convert a y4m back to PNGs:

./tools/y4m2png video.y4m -o video%05d.png

If you are converting a .y4m file that only contains a single frame (e.g., from one of the still-image subsets linked above), you can leave out the %05d tag. Conversion from PNG to Y4M uses the Rec 709 matrix with video levels, a box filter for chroma subsampling, and a triangular dither. Conversion back from Y4M to PNG uses the same matrix, levels, and box filter, but does not dither.

Daala Quickstart

2014-06-02T23:05:29Z

Rillian: /* Installation Procedure */ The ssh host string only supports people with commit access. Better to start with a read-only https url.

= Getting Started =

This is a simple guide to getting the code and encoding a simple video.

== Installation ==

=== Pre-requisites ===
* Standard build tools (autoconf, automake v1.11 or later, libtool, and a C compiler)
* git
* libogg (v1.3 or later)
* libpng
* libjpeg
* libcheck (v0.9.8 or later, can be skipped if you pass --disable-unit-tests to ./configure)
* libsdl (can by skipped if you pass --disable-player to ./configure)

Instructions for installing these packages are OS-specific (feel free to contribute some here, especially if you tried installing these somewhere and ran into difficulties; you will likely save other people some pain). If you have a package manager that has separate -dev versions with the public headers, make sure you install those in addition to the actual libraries.

=== Installation Procedure ===

Just run these commands:

git clone https://git.xiph.org/daala.git
cd daala
./autogen.sh
./configure
make

And optionally

make tools

Make sure you run the git clone operation on the same machine where you intend to use the code. Checking out a copy on Windows and then trying to use it on Linux will not work, as executable permissions and line-endings will not be set properly.

== Encoding a Video ==

If you do not have one, get a sample video or two in .y4m format from [https://media.xiph.org/video/derf/ media.xiph.org]. We also maintain a set of still-image collections in .y4m format:
* [https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz Subset 1] (50 images, small training set)
* [https://people.xiph.org/~tterribe/daala/subset2-y4m.tar.gz Subset 2] (1000 images, large training set)
* [https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz Subset 3] (50 images, small testing set)
* [https://people.xiph.org/~tterribe/daala/subset4-y4m.tar.gz Subset 4] (1000 images, large testing set)

Encode the video:

./examples/encoder_example -v 30 -k 256 video.y4m -o video.ogv

where
* video.y4m is the input video you want to encode,
* video.ogv is the name of the encoded video file to output,
* -v specifies the quality (currently from 0 to 511, where 0 is lossless), and
* -k specifies the maximum keyframe interval (this is currently 1 by default, which makes every frame a keyframe).

== Decoding a Video ==

Play the video:

./examples/player_example -p video.ogv

The -p option starts the player paused. Run

./examples/player_example --help

for information on the controls available while playing.

If you want to use a different player, you can decode the video back to .y4m with

./examples/dump_video video.ogv -o decoded_video.y4m

Many other players can play back these .y4m files, and other tools can convert them to various other formats.

== Using PNG Images ==

To encode a series of images:

make tools
./tools/png2y4m video%05d.png -o video.y4m

where %05d means your input images are named video00000.png, video00001.png, etc. You can leave out the %05d tag if you only want to convert a single image (which does not need to be numbered).

To convert a y4m back to PNGs:

./tools/y4m2png video.y4m -o video%05d.png

If you are converting a .y4m file that only contains a single frame (e.g., from one of the still-image subsets linked above), you can leave out the %05d tag. Conversion from PNG to Y4M uses the Rec 709 matrix with video levels, a box filter for chroma subsampling, and a triangular dither. Conversion back from Y4M to PNG uses the same matrix, levels, and box filter, but does not dither.

DaalaRoadmap

2014-05-18T16:48:55Z

Rillian: /* Daala Planning */ Link to etherpad for newer information.

== Daala Planning ==

This is an overview of the Daala project roadmap. '''Information on this page is highly subject to update and change.''' Please help reach out to us if you are interested in contributing to the project. We would love your help!

=== Plans for 2014 ===

See [https://daala.etherpad.mozilla.org/daala-plan-2014 this etherpad] for details. Most information has moved there. See also the weekly meeting minutes on [[Daala]] for current efforts.

=== Plans for September, 2013 to March, 2014 ===

==== Improve existing techniques ====

Examining and significantly modifying some of the basic coding tools within Daala to improve efficiency and quality:

1) Lapped Transforms
* https://people.xiph.org/~xiphmont/demo/daala/demo1.shtml
* http://thanglong.ece.jhu.edu/Tran/Pub/prepost.pdf
* https://research.microsoft.com/pubs/102075/malvar_elt_tsp1192.pdf

2) Frequency Domain Intraprediction
* https://people.xiph.org/~xiphmont/demo/daala/demo2.shtml

3) Time/Frequency resolution switching
* https://people.xiph.org/~xiphmont/demo/daala/demo3.shtml

4) Chroma from Luma
* http://people.xiph.org/~xiphmont/demo/daala/demo4.shtml

5) Motion Compensation tools

==== Research new techniques ====

Investigate the following to see if they should be adopted into Daala:

1) Edge-directed Interpolation
*http://elynxsdk.free.fr/ext-docs/Demosaicing/more/news0/New%20Edge-Directed%20Interpolation.pdf

2) Multi-frame Motion Compensation

==== Testing tools ====

1) Experiment with command-line encode/decode/performance tools
* Help people try the codec
* Self-testing
* Improvement metrics for casual contributors to verify changes

2) Prototype RTP in GIPS/webrtc.org/browser code

3) Prototype HTTP streaming.

=== Plans for March, 2014 to September, 2014 ===

From March, 2014 to June, 2014: Tuning the various coding tools and components of Daala (assumes investigation and major modifications of the basic coding tools are completed)

By September, 2014: Be able to show significant quality improvements compared to Daala's performance today (September, 2013).

=== Progress and planning tools we'll use along the way: ===
* Every 6-8 weeks the team will report on what he has accomplished.
* Every month the team will create a detailed task list of what they plan to do for that month.

Daala on Wheels

2014-05-18T16:44:20Z

Rillian: /* Work in progress */ Link to etherpad roadmap

Daala is the current working name of a next generation video codec— to be renamed once someone insists on something better. So far the best proposed alternative is PatentCake.

For now the purposes of this page is to collect notes about things which have been discussed in informal public IRC discussion about the next generation initiative. Participants in these discussions have included Timothy Terriberry, Jason Garrett-Glaser, Loren Merritt, Ben Schwartz, Greg Maxwell, and others.

See also: [https://xiph.org/daala/ https://xiph.org/daala/]

== Work in progress ==

* [https://daala.etherpad.mozilla.org/daala-plan-2014 2014 Roadmap]
* [[DaalaRoadmap]]
* [https://daala.etherpad.mozilla.org/workweek-201402 2014 February meetup]
* [https://daala.etherpad.mozilla.org/daala-meetup 2013 November meetup]
* [https://daala.etherpad.mozilla.org/coding-party-201309 2013 September code party]
* [https://daala.etherpad.mozilla.org/august-todo August task tracking]
* [https://daala.etherpad.mozilla.org/july-todo July tasks]
* [https://daala.etherpad.mozilla.org/june-todo June tasks]

== Weekly meetings ==

We've been having weekly progress meetings on mumble.

* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]
* 2012 August 17 - no meeting
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]
* 2012 August 31 - no meeting
* 2012 September 7 - no meeting
* 2012 September 14 - no meeting
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]
* 20120 October 26 -
* 2012 Novemeber 2 - no meeting
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects
* [[DaalaMeeting20140121|2014 January 21]] - project planning
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq

= Techniques =

The discussed overall structure so far has been a variable size lapped-DCT block based codec with lapping done via pre/post filtering with a specially structured (lifting) linear phase transform along the edges along with overlapped block motion compensation and the expected trimmings. The lapping can be optimized for energy compaction and other useful properties, including invert-ability, and yields excellent results with efficient finite precision math.

Other components which have been discussed include:

==Techniques applicable to all frame types==
* Multisymbol arithmetic coding
** Timothy has some trial code showing speed-up proportional to the number of bits coded at once. (ec_test.c)
* Mode prediction using the previously decoded data, e.g. coding the mode using a probability function derived from trained predictors on the surrounding blocks.
** This will be terrible for robustness but may significantly reduce signalling overhead, allowing many more modes, and provide continuous adaptation between signalling free and fully signalled modes.
* Explore legendre polynomial basis transforms instead of DCT
** May have better perceptual properties and/or result in 'less compromised' efficient implementations.
* Coefficient domain prediction to allow efficient energy preserving quantization.
* Variable partition size/shape and the use of good predictors appears to remove most of the benefit of directional transforms.
** Perhaps 45deg is still useful?
** How does this change with partition sizes? Directional transforms are clearly not that useful with 4x4.
* Transform-post filtering to allow merging smaller transform blocks (like TF merging in CELT) may allow more flexible partitioning then outright using mixed block sizes.
* Perturbed quantization mode-signalling has been discussed but mostly laughed at. ;)
* Special block modes well suited to solid color/cartoon like content— avoiding ringing.
** Are pixel prediction modes too slow?
* In general— what markov random field techniques can be applied with acceptable performance. Any?
* Designed for parallel encode and decode within each frame
** Important because
*** the proposed techniques need a lot more CPU than H.264 and VP8 for both encode and decode
*** Moore's law for single-threaded throughput is dead. Future hardware is all multicore/GPU.
** Implies
*** Getting the order of application right for the lapping filters.
*** Mandatory slicing? Maybe some kind of multilevel entropy coding to reduce redundancy between slices while minimizing the single-threaded portion of decode.

* Using PVQ and energy conservation: see http://jmvalin.ca/video/video_pvq_v3.pdf

==Techniques applicable to inter frames==
* Using x264 as a test-bed Jason and Loren demonstrated 15% rate/distortion improvements from using 10-bit intermediaries and references, estimated as being 1/3rd from quality calculation in the 10-bit space, 1/3rd from the higher precision references, and 1/3rd from higher intermediate precision in calculations (e.g. MC filter processing).
** Increased reference precision competes for memory with increased number of references. The improvements demonstrated appear to be a greater win than increasing the reference count once there are four references or so.
* Super-resolution techniques for motion-compensation references have been discussed— in particular it appears that the half-pel location is where intelligent filtering matters the most so staged computation could be effectively used to allow more expensive filtering at that level.
** Edge-directed interpolation techniques might be effectively applied to increase motion compensation accuracy, but most of the techniques known to be very effective are too slow.
** Speculation has been offered that a significant part of MC inaccuracy may be due to blending in a physically incorrect (gamma-corrected) space, though no real conclusions were made. Academic papers on motion compensation accuracy seem to have ignored this issue.
* Timothy has an example code base for a variable partition size blocking-free motion compensation scheme which merges OBMC (overlapped block motion compensation) and CGI (control-grid interpolation) with an interesting prediction/sub-division scheme and whole-frame trellis optimization of motion vectors. (daala-exp)

==Basic features==
* YUV 4:4:4, 4:2:2 , 4:2:0 subsamplings, 8-bit, 10bit.
* Alpha channel — need testing material!
* 8-bit RGB compatible mode? (e.g. YCoCg, internally or at least flagging for it)
* Efficient 3D? — need testing material!
* Lossless?
** The value of this is disputable. If nothing else it's arguable that stuffing lossless into a lossy format may be the only way to get lossless into many people's hands. Also, see below
* Good support for decode side droppable frames?
** Hopefully the referencing structure will be flexible enough to enable this even if it's not an intentional feature.

==Frills==
* Optionally storing a checksum of the expected decoded frame for decoder/encoder mismatch detection.
* Expose the number of referential descendants of a given frame (or even the whole reference DAG) for most efficient allocation of FEC.

==Wingdings==
Crazy crap that might be interesting or at least fun to make fun of...
* >10bit?
** Use cases don't seem well enough defined yet. Significant complexity. Any prospective hardware developer may hire assassins.
** Possible compromise: the video reference structure contains a backbone that can be decoded at only N bits of depth (e.g. 10), and higher precisions are only supported outside of this reference chain.
**# Precision by truncation: decode is performed twice on each frame, identically, at low and high precision. The only difference between them is the bit-depth of the transform, or possibly of the transform and MC filters. Only low-precision outputs can be referenced by subsequent frames. Useful if high-precision content is still worth watching at low precision.
**# Precision by gamma: decode is performed once at low precision as normal. Then the output frame is converted to linear-light at high precision, after which another layer of residuals is added. The second layer can be permitted to reference previous high-precision frames... tricky to use both sets of references though. Useful if high precision is used for storing linear data, but people still want to watch it on "low-end" hardware.
* Some high end digital cameras are operating jpeg-derivatives in a special mode that keeps the image in the native linear RGB bayer format in order to avoid lossy/slow demosaicing on the camera. In particular this allows white balancing in post without excessive loss. Probably out of scope for Daala itself.
** Bayer, 4:2:0, 4:2:2, and Interlacing are all special cases of a more general pattern in which the output frames are decimated/subsampled in a regular fashion. All such subsamplings could be supported by a unified framework in which the video is always stored with all planes fully sampled, with a header indicating the recommended subsampling for display. In such cases, the encoder can regard the transform as highly overcomplete, and simply ignore unneeded coefficients (presumably by leaving high frequency residuals coded as zero). This structure would in effect turn the codec into a motion-compensated interpolating/deinterlacing filter. Whether this approach is sensible presumably depends in part on how the transform is structured. It would be especially easy if the transform's highest-frequencies were coded by a wavelet-like layer.
* Lossless intra-ability: The ability to losslessly rewrite any frame as an intra frame (perhaps with significant bitrate overhead) in order to make frame accurate cuts possible.
** Or best handled by making sure that containers have working pre-roll, but presumably common GOP sizes will be greater than the number of references so even if losslessly reencoding the references is expensive it may be cheaper than pre-roll. Do both?
** Can be had for 'free' if lossless is supported, plus the right header flags to restuff the references from lossless copies in a packed hidden frame.
** Use of explicitly (rather than staged) super-resolution and/or deeper references may make this functionality unattractive due to increased overhead.
* Internal overlays which could be swapped without re-encoding? (e.g. advertising, station ID). Could also be automatically generated by a Sufficiently Advanced™ encoder to improve efficiencies for static sprites over moving backgrounds.
** Complicates making the complexity bounded. No Sufficiently Advanced™ encoder likely to ever exist. But perhaps the station id/advertising uses fully justify this.
** Could be done externally to the video codec, but if so it's no likely to be useful for anyone ever.
* A secondary reference implementation in OpenCL, maintained throughout development, to make sure that the codec is GPU-friendly and can be done efficiently using OpenCL primitives.
* SWAR-friendly arithmetic. For example, choosing transform coefficients so that no intermediate product overflows 16 bits (tricky for signed values) can sometimes enable (e.g.) 4 parallel operations in one uint64_t. This can allow a pure C reference implementation to run faster, which is valuable for initial adoption and ports to new platforms.
* Parametric decode-side blur.
** Symmetrical blur in regions that are smooth on scales longer than the block size. Could be signaled or derived from observed DC values.
** Motion blur so that moving objects are blurred along the motion vector. May require coding a shutter speed parameter (0..1 as a fraction of the inter-frame interval).
* Fancy block property prediction. (Not clear how these prediction interact with intra pred)
** Predict block properties (quantizer, energy, etc.) from MV. (0,0) probably means small delta. Larger MV's may correspond to larger deltas ... although at low shutter speeds large MVs may correlate with reduced overall HF energy.
** Predict delta spectral shape from source block spectral shape. HF/LF ratio of the delta may be correlated with the same ratio in its source blocks. Works well with decode-side fDCT.

==Negative results==

* Using Kurtosis for detecting text in a frame
** The idea was to detect a Bernouilli distribution but it's not robust and too noisy

OggOpusImplementation

2014-02-26T00:37:27Z

Rillian: /* Chrome */ gain and end trimming seem to respected now.

== Implementation Status ==

Implementation status of the [https://tools.ietf.org/html/draft-ietf-codec-oggopus Ogg Opus draft]. This draft describes encapsulation of Opus audio in the Ogg container to make <tt>.opus</tt> files and streams.

What follows is a brief summary of major implementations of the draft, and their status.
This is intended to help understand the status of each portion of the draft, per [https://tools.ietf.org/html/rfc6982 RFC 6982].

=== opus-tools ===

The initial development implementation of this draft was in the opusenc, opusdec, and opusinfo command-line utilities, part of the opus-tools package and repository.
While still 'development' status (pre-1.0) these utilities are in active public use, and have shipped with Linux distributions as well as homebrew and MacPorts for OS X.
Together they implement basic read, write and playback support of Ogg Opus files including metadata, multichannel, start and end trimming, the gain field, live streams, and chained files, but currently do not support seeking.

This implementation is open source.

* https://git.xiph.org/?p=opus-tools.git
* http://www.opus-codec.org/downloads/

=== opusfile ===

The opusfile library is a separate implementation of this draft as a helper library for demuxing and decoding.
Like opus-tools, it supports metadata, multichannel, start and end trimming, the gain field, live streams, and chained files.
Its primary focus is efficient seeking, including over HTTP(S) and in chained streams.
It currently does not create Ogg Opus files.
This library is in early development and is not widely deployed, though several projects are currently using it, including xmms2, taglib, and cmus, and it is shipped in some Linux distributions and in homebrew.

This implementation is open source.

* https://git.xiph.org/?p=opusfile.git
* http://www.opus-codec.org/downloads/

=== Firefox ===

The Firefox web browser is a widely deployed implementation of this draft.
Basic playback support with the HTML5 <audio> element, including start and end trimming, the gain field, live streams, multiplexing with other streams (for, e.g., the <video> tag), and seeking, was added in Firefox 15, in production release starting August 28, 2012.
Multichannel support was added in Firefox 17, in production release starting November 20, 2012.
Metadata support was added in Firefox 18, in production release starting January 8, 2013.
Chained file support (as streams only, with seeking disabled) was added in Firefox 20, in production release starting April 2, 2013.
Encoding support was added in Firefox 26, in production release starting December 10, 2013.

This implementation is open source.

* https://mozilla.org/firefox/
* https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/
* https://bugzilla.mozilla.org/show_bug.cgi?id=674225
* https://bugzilla.mozilla.org/show_bug.cgi?id=748144
* https://bugzilla.mozilla.org/show_bug.cgi?id=778050
* https://bugzilla.mozilla.org/show_bug.cgi?id=455165
* https://bugzilla.mozilla.org/show_bug.cgi?id=842243

=== Chrome ===

Google Chrome is a widely distributed implementation of this draft. It added support with the HTML5 <audio> element in M25 and enabled it by default in M33 released in February 2014.
This implementation currently does not support chained files.
Prior to M33 support required passing --enable-opus-playback on the command line when invoking the executable.

This implementation is based on open source code in Chromium, Blink, and FFmpeg.

* https://www.google.com/intl/en/chrome/browser/
* https://www.google.com/intl/en/chrome/browser/canary.html
* https://code.google.com/p/chromium/issues/detail?id=104241

=== GStreamer ===

The GStreamer media framework includes an implementation of this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, multiplexing with other streams (e.g., video), and seeking.
Support was first added in early 2011, and is part of the 0.11 and 1.0.x releases.
The code implementing this draft is in the gst-plugins-bad collection, which generally indicates unsupported and/or experimental code, despite its release status.

This implementation is open source.

* http://gstreamer.net/
* http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/

=== FFmpeg ===

The popular media framework and conversion tool FFmpeg implements this draft. It supports encoding and decoding, multiplexing and demultiplexing with other streams, metadata, multichannel, start and end trimming, the gain field, live streams, and seeking.

This implementation is open source.

* https://ffmpeg.org/

=== libav ===

The development repository for libav implements this draft, similar to FFmpeg.

This implementation is open source.

* https://libav.org/

=== VLC ===

VLC is another widely deployed implementation of demuxing, decoding, and playback support for this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, seeking, chained files (though seeking does not work correctly with chained files), and multiplexing with other streams (e.g., video).
Opus support was added in version 2.0.4, released on October 18, 2012.

This implementation is open source.

* https://www.videolan.org/vlc/
* https://git.videolan.org/?p=vlc.git
* https://trac.videolan.org/vlc/ticket/7185

=== foobar2000 ===

A popular Windows application, foobar2000 implements read, write, and playback support for this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, and seeking.
Opus support was added in version 1.1.14, released on August 17, 2012.
Encoding support is implemented using opusenc from opus-tools.

This implementation is closed source.

* http://www.foobar2000.org/

=== Rockbox ===

Rockbox is an established alternative firmware for portable music players (typically small, embedded devices) that implements demuxing, decoding, and playback support for this draft starting with version 3.13 released March 5, 2013.
It supports metadata, start and end trimming, the gain field, and seeking.
It does not currently support multichannel or chained files.

This implementation is open source.

* http://www.rockbox.org/
* http://git.rockbox.org/?p=rockbox.git
* http://gerrit.rockbox.org/r/#/c/300/

=== Youki3 ===

Youki3 is a media player for the Android mobile operating system. It provides OPUS metadata reading support via TagLib [(c) Scott Wheeler; ported to Android] and playback via LibVLC [also see the VLC section above please; (C) VideoLAN developers].

It is currently in a closed beta, however you may get access by joining the Youki3 BETA-Test Google+ community, and then installing it from the Google Play Store

* https://plus.google.com/communities/102114949476184273984

The app source is currently closed, however since it utilizes LibVLC for playback, the respective source is open.

OggOpusImplementation

2014-02-26T00:18:15Z

Rillian: /* Chrome */ Chrome 33 is released

== Implementation Status ==

Implementation status of the [https://tools.ietf.org/html/draft-ietf-codec-oggopus Ogg Opus draft]. This draft describes encapsulation of Opus audio in the Ogg container to make <tt>.opus</tt> files and streams.

What follows is a brief summary of major implementations of the draft, and their status.
This is intended to help understand the status of each portion of the draft, per [https://tools.ietf.org/html/rfc6982 RFC 6982].

=== opus-tools ===

The initial development implementation of this draft was in the opusenc, opusdec, and opusinfo command-line utilities, part of the opus-tools package and repository.
While still 'development' status (pre-1.0) these utilities are in active public use, and have shipped with Linux distributions as well as homebrew and MacPorts for OS X.
Together they implement basic read, write and playback support of Ogg Opus files including metadata, multichannel, start and end trimming, the gain field, live streams, and chained files, but currently do not support seeking.

This implementation is open source.

* https://git.xiph.org/?p=opus-tools.git
* http://www.opus-codec.org/downloads/

=== opusfile ===

The opusfile library is a separate implementation of this draft as a helper library for demuxing and decoding.
Like opus-tools, it supports metadata, multichannel, start and end trimming, the gain field, live streams, and chained files.
Its primary focus is efficient seeking, including over HTTP(S) and in chained streams.
It currently does not create Ogg Opus files.
This library is in early development and is not widely deployed, though several projects are currently using it, including xmms2, taglib, and cmus, and it is shipped in some Linux distributions and in homebrew.

This implementation is open source.

* https://git.xiph.org/?p=opusfile.git
* http://www.opus-codec.org/downloads/

=== Firefox ===

The Firefox web browser is a widely deployed implementation of this draft.
Basic playback support with the HTML5 <audio> element, including start and end trimming, the gain field, live streams, multiplexing with other streams (for, e.g., the <video> tag), and seeking, was added in Firefox 15, in production release starting August 28, 2012.
Multichannel support was added in Firefox 17, in production release starting November 20, 2012.
Metadata support was added in Firefox 18, in production release starting January 8, 2013.
Chained file support (as streams only, with seeking disabled) was added in Firefox 20, in production release starting April 2, 2013.
Encoding support was added in Firefox 26, in production release starting December 10, 2013.

This implementation is open source.

* https://mozilla.org/firefox/
* https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/
* https://bugzilla.mozilla.org/show_bug.cgi?id=674225
* https://bugzilla.mozilla.org/show_bug.cgi?id=748144
* https://bugzilla.mozilla.org/show_bug.cgi?id=778050
* https://bugzilla.mozilla.org/show_bug.cgi?id=455165
* https://bugzilla.mozilla.org/show_bug.cgi?id=842243

=== Chrome ===

Google Chrome is a widely distributed implementation of this draft. It added support with the HTML5 <audio> element in M25 and enabled it by default in M33 released in February 2014.
This implementation currently does not support end trimming, the gain tag, or chained files.
Prior to M33 support required passing --enable-opus-playback on the command line when invoking the executable.

This implementation is based on open source code in Chromium, Blink, and FFmpeg.

* https://www.google.com/intl/en/chrome/browser/
* https://www.google.com/intl/en/chrome/browser/canary.html
* https://code.google.com/p/chromium/issues/detail?id=104241

=== GStreamer ===

The GStreamer media framework includes an implementation of this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, multiplexing with other streams (e.g., video), and seeking.
Support was first added in early 2011, and is part of the 0.11 and 1.0.x releases.
The code implementing this draft is in the gst-plugins-bad collection, which generally indicates unsupported and/or experimental code, despite its release status.

This implementation is open source.

* http://gstreamer.net/
* http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/

=== FFmpeg ===

The popular media framework and conversion tool FFmpeg implements this draft. It supports encoding and decoding, multiplexing and demultiplexing with other streams, metadata, multichannel, start and end trimming, the gain field, live streams, and seeking.

This implementation is open source.

* https://ffmpeg.org/

=== libav ===

The development repository for libav implements this draft, similar to FFmpeg.

This implementation is open source.

* https://libav.org/

=== VLC ===

VLC is another widely deployed implementation of demuxing, decoding, and playback support for this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, seeking, chained files (though seeking does not work correctly with chained files), and multiplexing with other streams (e.g., video).
Opus support was added in version 2.0.4, released on October 18, 2012.

This implementation is open source.

* https://www.videolan.org/vlc/
* https://git.videolan.org/?p=vlc.git
* https://trac.videolan.org/vlc/ticket/7185

=== foobar2000 ===

A popular Windows application, foobar2000 implements read, write, and playback support for this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, and seeking.
Opus support was added in version 1.1.14, released on August 17, 2012.
Encoding support is implemented using opusenc from opus-tools.

This implementation is closed source.

* http://www.foobar2000.org/

=== Rockbox ===

Rockbox is an established alternative firmware for portable music players (typically small, embedded devices) that implements demuxing, decoding, and playback support for this draft starting with version 3.13 released March 5, 2013.
It supports metadata, start and end trimming, the gain field, and seeking.
It does not currently support multichannel or chained files.

This implementation is open source.

* http://www.rockbox.org/
* http://git.rockbox.org/?p=rockbox.git
* http://gerrit.rockbox.org/r/#/c/300/

=== Youki3 ===

Youki3 is a media player for the Android mobile operating system. It provides OPUS metadata reading support via TagLib [(c) Scott Wheeler; ported to Android] and playback via LibVLC [also see the VLC section above please; (C) VideoLAN developers].

It is currently in a closed beta, however you may get access by joining the Youki3 BETA-Test Google+ community, and then installing it from the Google Play Store

* https://plus.google.com/communities/102114949476184273984

The app source is currently closed, however since it utilizes LibVLC for playback, the respective source is open.

OggOpusImplementation

2014-02-07T22:46:10Z

Rillian: /* Chrome */ refer to chrome as widely distributed, even though M33 is still in beta.

== Implementation Status ==

Implementation status of the [https://tools.ietf.org/html/draft-ietf-codec-oggopus Ogg Opus draft]. This draft describes encapsulation of Opus audio in the Ogg container to make <tt>.opus</tt> files and streams.

What follows is a brief summary of major implementations of the draft, and their status.
This is intended to help understand the status of each portion of the draft, per [https://tools.ietf.org/html/rfc6982 RFC 6982].

=== opus-tools ===

The initial development implementation of this draft was in the opusenc, opusdec, and opusinfo command-line utilities, part of the opus-tools package and repository.
While still 'development' status (pre-1.0) these utilities are in active public use, and have shipped with Linux distributions as well as homebrew and MacPorts for OS X.
Together they implement basic read, write and playback support of Ogg Opus files including metadata, multichannel, start and end trimming, the gain field, live streams, and chained files, but currently do not support seeking.

This implementation is open source.

* https://git.xiph.org/?p=opus-tools.git
* http://www.opus-codec.org/downloads/

=== opusfile ===

The opusfile library is a separate implementation of this draft as a helper library for demuxing and decoding.
Like opus-tools, it supports metadata, multichannel, start and end trimming, the gain field, live streams, and chained files.
Its primary focus is efficient seeking, including over HTTP(S) and in chained streams.
It currently does not create Ogg Opus files.
This library is in early development and is not widely deployed, though several projects are currently using it, including xmms2, taglib, and cmus, and it is shipped in some Linux distributions and in homebrew.

This implementation is open source.

* https://git.xiph.org/?p=opusfile.git
* http://www.opus-codec.org/downloads/

=== Firefox ===

The Firefox web browser is a widely deployed implementation of this draft.
Basic playback support with the HTML5 <audio> element, including start and end trimming, the gain field, live streams, multiplexing with other streams (for, e.g., the <video> tag), and seeking, was added in Firefox 15, in production release starting August 28, 2012.
Multichannel support was added in Firefox 17, in production release starting November 20, 2012.
Metadata support was added in Firefox 18, in production release starting January 8, 2013.
Chained file support (as streams only, with seeking disabled) was added in Firefox 20, in production release starting April 2, 2013.
Encoding support was added in Firefox 26, in production release starting December 10, 2013.

This implementation is open source.

* https://mozilla.org/firefox/
* https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/
* https://bugzilla.mozilla.org/show_bug.cgi?id=674225
* https://bugzilla.mozilla.org/show_bug.cgi?id=748144
* https://bugzilla.mozilla.org/show_bug.cgi?id=778050
* https://bugzilla.mozilla.org/show_bug.cgi?id=455165
* https://bugzilla.mozilla.org/show_bug.cgi?id=842243

=== Chrome ===

Google Chrome is a widely distributed implementation of this draft. It added support for this draft with the HTML5 <audio> element in M25 and enabled it by default in M33 for stable release in early 2014.
This implementation currently does not support end trimming, the gain tag, or chained files.
Prior to M33 support required passing --enable-opus-playback on the command line when invoking the executable.

This implementation is based on open source code in Chromium, Blink, and FFmpeg.

* https://www.google.com/intl/en/chrome/browser/
* https://www.google.com/intl/en/chrome/browser/canary.html
* https://code.google.com/p/chromium/issues/detail?id=104241

=== GStreamer ===

The GStreamer media framework includes an implementation of this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, multiplexing with other streams (e.g., video), and seeking.
Support was first added in early 2011, and is part of the 0.11 and 1.0.x releases.
The code implementing this draft is in the gst-plugins-bad collection, which generally indicates unsupported and/or experimental code, despite its release status.

This implementation is open source.

* http://gstreamer.net/
* http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/

=== FFmpeg ===

The popular media framework and conversion tool FFmpeg implements this draft. It supports encoding and decoding, multiplexing and demultiplexing with other streams, metadata, multichannel, start and end trimming, the gain field, live streams, and seeking.

This implementation is open source.

* https://ffmpeg.org/

=== libav ===

The development repository for libav implements this draft, similar to FFmpeg.

This implementation is open source.

* https://libav.org/

=== VLC ===

VLC is another widely deployed implementation of demuxing, decoding, and playback support for this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, seeking, chained files (though seeking does not work correctly with chained files), and multiplexing with other streams (e.g., video).
Opus support was added in version 2.0.4, released on October 18, 2012.

This implementation is open source.

* https://www.videolan.org/vlc/
* https://git.videolan.org/?p=vlc.git
* https://trac.videolan.org/vlc/ticket/7185

=== foobar2000 ===

A popular Windows application, foobar2000 implements read, write, and playback support for this draft.
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, and seeking.
Opus support was added in version 1.1.14, released on August 17, 2012.
Encoding support is implemented using opusenc from opus-tools.

This implementation is closed source.

* http://www.foobar2000.org/

=== Rockbox ===

Rockbox is an established alternative firmware for portable music players (typically small, embedded devices) that implements demuxing, decoding, and playback support for this draft starting with version 3.13 released March 5, 2013.
It supports metadata, start and end trimming, the gain field, and seeking.
It does not currently support multichannel or chained files.

This implementation is open source.

* http://www.rockbox.org/
* http://git.rockbox.org/?p=rockbox.git
* http://gerrit.rockbox.org/r/#/c/300/

Daala on Wheels

2014-02-03T16:32:38Z

Rillian: /* Work in progress */ new code party links

Daala is the current working name of a next generation video codec— to be renamed once someone insists on something better. So far the best proposed alternative is PatentCake.

For now the purposes of this page is to collect notes about things which have been discussed in informal public IRC discussion about the next generation initiative. Participants in these discussions have included Timothy Terriberry, Jason Garrett-Glaser, Loren Merritt, Ben Schwartz, Greg Maxwell, and others.

See also: [https://xiph.org/daala/ https://xiph.org/daala/]

== Work in progress ==

* [[DaalaRoadmap]]
* [https://daala.etherpad.mozilla.org/workweek-201402 2014 February meetup]
* [https://daala.etherpad.mozilla.org/daala-meetup 2013 November meetup]
* [https://daala.etherpad.mozilla.org/coding-party-201309 2013 September code party]
* [https://daala.etherpad.mozilla.org/august-todo August task tracking]
* [https://daala.etherpad.mozilla.org/july-todo July tasks]
* [https://daala.etherpad.mozilla.org/june-todo June tasks]

== Weekly meetings ==

We've been having weekly progress meetings on mumble.

* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]
* 2012 August 17 - no meeting
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]
* 2012 August 31 - no meeting
* 2012 September 7 - no meeting
* 2012 September 14 - no meeting
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]
* 20120 October 26 -
* 2012 Novemeber 2 - no meeting
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects
* [[DaalaMeeting20140121|2014 January 21]] - project planning

= Techniques =

The discussed overall structure so far has been a variable size lapped-DCT block based codec with lapping done via pre/post filtering with a specially structured (lifting) linear phase transform along the edges along with overlapped block motion compensation and the expected trimmings. The lapping can be optimized for energy compaction and other useful properties, including invert-ability, and yields excellent results with efficient finite precision math.

Other components which have been discussed include:

==Techniques applicable to all frame types==
* Multisymbol arithmetic coding
** Timothy has some trial code showing speed-up proportional to the number of bits coded at once. (ec_test.c)
* Mode prediction using the previously decoded data, e.g. coding the mode using a probability function derived from trained predictors on the surrounding blocks.
** This will be terrible for robustness but may significantly reduce signalling overhead, allowing many more modes, and provide continuous adaptation between signalling free and fully signalled modes.
* Explore legendre polynomial basis transforms instead of DCT
** May have better perceptual properties and/or result in 'less compromised' efficient implementations.
* Coefficient domain prediction to allow efficient energy preserving quantization.
* Variable partition size/shape and the use of good predictors appears to remove most of the benefit of directional transforms.
** Perhaps 45deg is still useful?
** How does this change with partition sizes? Directional transforms are clearly not that useful with 4x4.
* Transform-post filtering to allow merging smaller transform blocks (like TF merging in CELT) may allow more flexible partitioning then outright using mixed block sizes.
* Perturbed quantization mode-signalling has been discussed but mostly laughed at. ;)
* Special block modes well suited to solid color/cartoon like content— avoiding ringing.
** Are pixel prediction modes too slow?
* In general— what markov random field techniques can be applied with acceptable performance. Any?
* Designed for parallel encode and decode within each frame
** Important because
*** the proposed techniques need a lot more CPU than H.264 and VP8 for both encode and decode
*** Moore's law for single-threaded throughput is dead. Future hardware is all multicore/GPU.
** Implies
*** Getting the order of application right for the lapping filters.
*** Mandatory slicing? Maybe some kind of multilevel entropy coding to reduce redundancy between slices while minimizing the single-threaded portion of decode.

* Using PVQ and energy conservation: see http://jmvalin.ca/video/video_pvq_v3.pdf

==Techniques applicable to inter frames==
* Using x264 as a test-bed Jason and Loren demonstrated 15% rate/distortion improvements from using 10-bit intermediaries and references, estimated as being 1/3rd from quality calculation in the 10-bit space, 1/3rd from the higher precision references, and 1/3rd from higher intermediate precision in calculations (e.g. MC filter processing).
** Increased reference precision competes for memory with increased number of references. The improvements demonstrated appear to be a greater win than increasing the reference count once there are four references or so.
* Super-resolution techniques for motion-compensation references have been discussed— in particular it appears that the half-pel location is where intelligent filtering matters the most so staged computation could be effectively used to allow more expensive filtering at that level.
** Edge-directed interpolation techniques might be effectively applied to increase motion compensation accuracy, but most of the techniques known to be very effective are too slow.
** Speculation has been offered that a significant part of MC inaccuracy may be due to blending in a physically incorrect (gamma-corrected) space, though no real conclusions were made. Academic papers on motion compensation accuracy seem to have ignored this issue.
* Timothy has an example code base for a variable partition size blocking-free motion compensation scheme which merges OBMC (overlapped block motion compensation) and CGI (control-grid interpolation) with an interesting prediction/sub-division scheme and whole-frame trellis optimization of motion vectors. (daala-exp)

==Basic features==
* YUV 4:4:4, 4:2:2 , 4:2:0 subsamplings, 8-bit, 10bit.
* Alpha channel — need testing material!
* 8-bit RGB compatible mode? (e.g. YCoCg, internally or at least flagging for it)
* Efficient 3D? — need testing material!
* Lossless?
** The value of this is disputable. If nothing else it's arguable that stuffing lossless into a lossy format may be the only way to get lossless into many people's hands. Also, see below
* Good support for decode side droppable frames?
** Hopefully the referencing structure will be flexible enough to enable this even if it's not an intentional feature.

==Frills==
* Optionally storing a checksum of the expected decoded frame for decoder/encoder mismatch detection.
* Expose the number of referential descendants of a given frame (or even the whole reference DAG) for most efficient allocation of FEC.

==Wingdings==
Crazy crap that might be interesting or at least fun to make fun of...
* >10bit?
** Use cases don't seem well enough defined yet. Significant complexity. Any prospective hardware developer may hire assassins.
** Possible compromise: the video reference structure contains a backbone that can be decoded at only N bits of depth (e.g. 10), and higher precisions are only supported outside of this reference chain.
**# Precision by truncation: decode is performed twice on each frame, identically, at low and high precision. The only difference between them is the bit-depth of the transform, or possibly of the transform and MC filters. Only low-precision outputs can be referenced by subsequent frames. Useful if high-precision content is still worth watching at low precision.
**# Precision by gamma: decode is performed once at low precision as normal. Then the output frame is converted to linear-light at high precision, after which another layer of residuals is added. The second layer can be permitted to reference previous high-precision frames... tricky to use both sets of references though. Useful if high precision is used for storing linear data, but people still want to watch it on "low-end" hardware.
* Some high end digital cameras are operating jpeg-derivatives in a special mode that keeps the image in the native linear RGB bayer format in order to avoid lossy/slow demosaicing on the camera. In particular this allows white balancing in post without excessive loss. Probably out of scope for Daala itself.
** Bayer, 4:2:0, 4:2:2, and Interlacing are all special cases of a more general pattern in which the output frames are decimated/subsampled in a regular fashion. All such subsamplings could be supported by a unified framework in which the video is always stored with all planes fully sampled, with a header indicating the recommended subsampling for display. In such cases, the encoder can regard the transform as highly overcomplete, and simply ignore unneeded coefficients (presumably by leaving high frequency residuals coded as zero). This structure would in effect turn the codec into a motion-compensated interpolating/deinterlacing filter. Whether this approach is sensible presumably depends in part on how the transform is structured. It would be especially easy if the transform's highest-frequencies were coded by a wavelet-like layer.
* Lossless intra-ability: The ability to losslessly rewrite any frame as an intra frame (perhaps with significant bitrate overhead) in order to make frame accurate cuts possible.
** Or best handled by making sure that containers have working pre-roll, but presumably common GOP sizes will be greater than the number of references so even if losslessly reencoding the references is expensive it may be cheaper than pre-roll. Do both?
** Can be had for 'free' if lossless is supported, plus the right header flags to restuff the references from lossless copies in a packed hidden frame.
** Use of explicitly (rather than staged) super-resolution and/or deeper references may make this functionality unattractive due to increased overhead.
* Internal overlays which could be swapped without re-encoding? (e.g. advertising, station ID). Could also be automatically generated by a Sufficiently Advanced™ encoder to improve efficiencies for static sprites over moving backgrounds.
** Complicates making the complexity bounded. No Sufficiently Advanced™ encoder likely to ever exist. But perhaps the station id/advertising uses fully justify this.
** Could be done externally to the video codec, but if so it's no likely to be useful for anyone ever.
* A secondary reference implementation in OpenCL, maintained throughout development, to make sure that the codec is GPU-friendly and can be done efficiently using OpenCL primitives.
* SWAR-friendly arithmetic. For example, choosing transform coefficients so that no intermediate product overflows 16 bits (tricky for signed values) can sometimes enable (e.g.) 4 parallel operations in one uint64_t. This can allow a pure C reference implementation to run faster, which is valuable for initial adoption and ports to new platforms.
* Parametric decode-side blur.
** Symmetrical blur in regions that are smooth on scales longer than the block size. Could be signaled or derived from observed DC values.
** Motion blur so that moving objects are blurred along the motion vector. May require coding a shutter speed parameter (0..1 as a fraction of the inter-frame interval).
* Fancy block property prediction. (Not clear how these prediction interact with intra pred)
** Predict block properties (quantizer, energy, etc.) from MV. (0,0) probably means small delta. Larger MV's may correspond to larger deltas ... although at low shutter speeds large MVs may correlate with reduced overall HF energy.
** Predict delta spectral shape from source block spectral shape. HF/LF ratio of the delta may be correlated with the same ratio in its source blocks. Works well with decode-side fDCT.

==Negative results==

* Using Kurtosis for detecting text in a frame
** The idea was to detect a Bernouilli distribution but it's not robust and too noisy

OpusTodo

2014-01-27T16:50:22Z

Rillian: /* Experiments */ I believe these branches are obsolete post-1.1

== For 1.1.1 ==
* Unconstrained SILK VBR

== Spec ==
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]

== Website ==
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ...
* Promotional material (some nice free or Public domain sounds in Opus format)

== Other ==

* Oggz-validate (should also validate opus toc)

== Opus-tools ==
* Port opusdec to libopusfile/libopusurl.
* A simple real time streaming example tool
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?
** Make --sniff save one file per
** Implement DTLS-SRTP. See webrtc.
** audio capture/encode, decode/playback?
** Parse and act on sdp for convenience and testing.

* Replaygain (half done— needs a gain tool)

== Surround work ==

* Apply spreading to energy masking
* More conservative energy masking (not just mean difference) and dynalloc
* Allow SILK/hybrid on center channel for voice?

== Psychoacoustic stuff ==

* Adaptive width narrowing and forced intensity stereo bands

== Optimisations ==

* Vectorising comb_filter()
* Use 16-bit mul plus shift in denormalise_bands()
* Optimise MDCT somehow
* Merge MIPS optimisations

== Future work ==
* psymodel based VBR
* Remove copy in inverse MDCT
* Save some float<->int conversions
* Improvements to LP mode CBR (greg has some code)
* Better handling for the case where FEC has a different bandwidth than the current mode
* PLC transitions on unprotected SILK-SILK bandwidth changes?
* Figure out how to use speech/music detection optimally
** find optimal switching time (low energy/tonality)
* Improve variable frame size

OpusTodo

2014-01-27T16:49:42Z

Rillian: /* Opus-tools */ mention opusfile->opusdec

== For 1.1.1 ==
* Unconstrained SILK VBR

== Spec ==
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]

== Website ==
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ...
* Promotional material (some nice free or Public domain sounds in Opus format)

== Other ==

* Oggz-validate (should also validate opus toc)

== Opus-tools ==
* Port opusdec to libopusfile/libopusurl.
* A simple real time streaming example tool
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?
** Make --sniff save one file per
** Implement DTLS-SRTP. See webrtc.
** audio capture/encode, decode/playback?
** Parse and act on sdp for convenience and testing.

* Replaygain (half done— needs a gain tool)

== Surround work ==

* Apply spreading to energy masking
* More conservative energy masking (not just mean difference) and dynalloc
* Allow SILK/hybrid on center channel for voice?

== Psychoacoustic stuff ==

* Adaptive width narrowing and forced intensity stereo bands

== Experiments ==

* Test exp_analysis and void_my_warranty.patch

== Optimisations ==

* Vectorising comb_filter()
* Use 16-bit mul plus shift in denormalise_bands()
* Optimise MDCT somehow
* Merge MIPS optimisations

== Future work ==
* psymodel based VBR
* Remove copy in inverse MDCT
* Save some float<->int conversions
* Improvements to LP mode CBR (greg has some code)
* Better handling for the case where FEC has a different bandwidth than the current mode
* PLC transitions on unprotected SILK-SILK bandwidth changes?
* Figure out how to use speech/music detection optimally
** find optimal switching time (low energy/tonality)
* Improve variable frame size

OpusTodo

2014-01-27T16:47:36Z

Rillian: updates on things I know we've done

== For 1.1.1 ==
* Unconstrained SILK VBR

== Spec ==
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]

== Website ==
* De-uglify webpage - some suggestions: write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?), and the prop. ones), write about implementations (is there only one so far?), comparison table (Opus, Vorbis, Speex, ..., MP5) of features (channels, freq, bits per sample, license, language (C89), integer impl. (Vorbis decoder only, Opus YES, ...), future use in video files (Theora? Dirac? WebM? other future codecs...), audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ...
* Promotional material (some nice free or Public domain sounds in Opus format)

== Other ==

* Oggz-validate (should also validate opus toc)

== Opus-tools ==
* A simple real time streaming example tool
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]
** Make <code>opusrtp rtp://example.com:5431/</code> listen to that host and port and mux packets from there. Generalize the cpac bases --sniff implementation
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?
** Make --sniff save one file per
** Implement DTLS-SRTP. See webrtc.
** audio capture/encode, decode/playback?
** Parse and act on sdp for convenience and testing.

* Replaygain (half done— needs a gain tool)

== Surround work ==

* Apply spreading to energy masking
* More conservative energy masking (not just mean difference) and dynalloc
* Allow SILK/hybrid on center channel for voice?

== Psychoacoustic stuff ==

* Adaptive width narrowing and forced intensity stereo bands

== Experiments ==

* Test exp_analysis and void_my_warranty.patch

== Optimisations ==

* Vectorising comb_filter()
* Use 16-bit mul plus shift in denormalise_bands()
* Optimise MDCT somehow
* Merge MIPS optimisations

== Future work ==
* psymodel based VBR
* Remove copy in inverse MDCT
* Save some float<->int conversions
* Improvements to LP mode CBR (greg has some code)
* Better handling for the case where FEC has a different bandwidth than the current mode
* PLC transitions on unprotected SILK-SILK bandwidth changes?
* Figure out how to use speech/music detection optimally
** find optimal switching time (low energy/tonality)
* Improve variable frame size