XiphWiki - User contributions [en]

Tremor

2006-07-06T05:34:25Z

Tbullock: Restored after Vandalism

Tremor is a fixed-point version of the Ogg Vorbis decoder for those platforms that can't do floating point math.

== Platforms ==

== Texas Instruments TMS320C55x DSP Family ==

Download the generic lowmem source using [http://subversion.tigris.org/ Subversion].
This is probably the version you want to start working with for a DSP.

svn co http://svn.xiph.org/branches/lowmem-branch/Tremor/

There is also a [http://svn.xiph.org/branches/lowmem-no-byte/Tremor/ no-byte branch] for platforms whose smallest data unit is larger than 8 bits.

Required / Suggested Changes to the code as downloaded:

* Roland Wintersteller's various fixes
See the [http://lists.xiph.org/pipermail/tremor/2004-October/001114.html mailing list entry]
* Johannes Sandvall's performance improvements
See the [http://lists.xiph.org/pipermail/tremor/2004-March/000957.html mailing list entry] or just [http://www.sandvall.nu/patch download]
* alloca removal
The TI compiler does not support this.
* misc compiler warning fixes
* hooks to TI DSPLIB functions cfft3216_NOSCALE and cbrev32
These are part of the TI DSPLIB which can be [http://www-s.ti.com/sc/psheets/sprc100/sprc100.zip downloaded] from the TI website.
* [http://lists.xiph.org/pipermail/tremor/attachments/20041029/30a4905c/misc.h 64-bit math functions]
* converting all ints assumed to be 32 bits to ogg_int32_t

== Links ==

* [http://lists.xiph.org/pipermail/tremor/ Tremor Mailing List] - lots of info here, but have to wade through a lot!

Talk:Tremor

2006-07-06T05:33:11Z

Tbullock: Restored after Vandalism

Vorbis

2006-07-06T05:31:28Z

Tbullock: Restored after Vandalism

'''Vorbis''' is a patent-clear, fully open general purpose audio encoding format standard that rivals or surpasses the 'upcoming' generation of proprietary coders ([[Wikipedia:Advanced Audio Coding|AAC]] and [[Wikipedia:TwinVQ|TwinVQ]], also known as VQF). Vorbis is most often used in the [[Ogg]] container format. It is then called Ogg Vorbis.

libvorbis, a BSD-licensed source implementation of Vorbis as a library is available; See the [http://www.xiph.org/ogg/vorbis/ Ogg Vorbis page] for documentation, downloads and distribution terms.

Further, many players support Ogg Vorbis; see [http://www.vorbis.com/ vorbis.com] for a list of all the players we know about.

== More information ==

* [[VorbisHardware]]: List of hardware-players supporting Ogg Vorbis
* [[Games that use Vorbis]]: List of games using Ogg Vorbis
* [[VorbisTools]]: Reference tools maintained by Xiph.org
* [[VorbisSoftwarePlayers]]: List of media players that can play Ogg Vorbis
* [[VorbisSoftwareEncoders]]: List of libvorbis frontends
* [[VorbisDecoders]]: List of decoders (e.g. Xiph, Tremor, JOrbis, etc)
* [[VorbisEncoders]]: List of encoders (e.g. Xiph, aoTuV, GT)

== External links ==

* [http://www.vorbis.com/ Vorbis.com]
* [[Wikipedia: Vorbis]]
* [http://www.rjamorim.com/test/multiformat128/results.html 128kbps public listening test]
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=35438 80kbps personal listening test]
* [http://www.hydrogenaudio.org/forums/index.php?showtopic=36465 180kbps personal listening test with classical music]
* [http://www.maresweb.de/listening-tests/mf-128-1/results.htm 128kbps public listening test]

Translations

2006-07-06T05:30:23Z

Tbullock: Restored after Vandalism

The Xiph.org projects are mainly in english. Some of this projects are used by many non-english speaking users. They will be happy to find some '''help''' in their own language.
The main goal of this page is to answer those two questions:

- how are we going to translate the docs?

- how are the translated docs going to be integrated on the websites?

'''How are we going to translate the docs?'''

* First a translation need some translators. The Xiph Foundation needs to call for help. Many users are ready to help but need a sign and a clear TODO list. Prior to translate all the docs, users can write some howtos in their mother language or a simple FAQ.

The more simple it is, the more I love it.
You're going to read the icecast doc, you see a link "Won't you help us in translating or reviewing this doc?" this link takes you to a _simple_ webpage with a mailform, you send a mail and that's it.
This link can drive the users to a simple web formular with some checkboxes : what would I translate, have I ever made some translation work, etc. Then the formular sends a mail to a translation coordinator. The coordinator sends some parts of the docs to the users and when the docs is translated, it is merged into the main doc tree. At the begining a new user can start in re-reading an already translated doc.

'''How are the translated docs going to be integrated on the websites?'''

* a newly translated doc can only be integrated on a website by a coordinator or a webmaster. The coordinator needs to be formed (?) by the webmaster in order to produce useable webpages. The coordinator has to produce some translation how-tos for the translators (some useful KDE translator stuff here).

On a FTP point of view, that's quite simple:

/docs

/docs/index.php

/docs/en/... -> all the doc in english

/docs/fr/... -> all the doc in french

/docs/de/... -> all the doc in german

And so on.

* Instead maybe we could use something like

/docs/index.php

/docs/index.fr.php

/docs/index.de.php

There probably isn't any reason to use a .en as all of the official docs are in English anyway.

The main index.php page lists the docs for every language.

- if the doc is fully translated and reviewed, the doc is ok

- if the doc needs to be re-readed, a link, at the top of the page asks for some volunteers

- if the doc needs to be translated, a link, at the top of the page asks for some volunteers.

'''How are we going to start?'''

IMHO Icecast is the Xiph project having the biggest need in translation. I suggest that we begin with it.

'''1''' - Modify the http://www.icecast.org/docs/ page.

Quoting and editing : "''Here is an index to the icecast documentation we know about. If there is something out ther on the Web that you know about, but is not listed here, send an email to webmaster@icecast.org.
The icecast documentation is going to be avalaible in many languages. Feel free to volunteer and give your help: click on your flag''

'''2''' - Add a flag list.

Each flag takes the user on its http://www.icecast.org/docs/ page. (this page needs a PHP file in order to simply list the docs)

'''3''' - Each doc links takes the user to a specific doc homepage with the call for help.

'''4''' - Produce some translation guidelines.

Talk:Vorbis

2006-07-06T05:28:34Z

Tbullock: Restored after Vandalism

What about non-standard encoders and tunings?

Shouldn't you make a page about how to encode vorbis files?

[JohnRipley] How about a list of third party implementations of the Vorbis codec itself? For example: JOrbis, and mine :)

== Windows Media Player Encoding ==

[cparker] I'd like to know how to enable Windows Media Player to encode vorbis files directly from the "Rip" tab. I'm using Windows Media Player 9-10. I checked vorbis.com[http://vorbis.com], and it appears to be quite outdated. (It makes a reference to irc.xiph.org.)

Speex

2006-07-06T05:21:41Z

Tbullock: Restored after Vandalism

= Speex =

The [http://www.speex.org/ Speex homepage] has all the project info.

== Tasks ==

These are some improvements that could be made to Speex. Let [mailto:speex-dev@xiph.org us] know if you'd like to work on one of them.

* Speech/signal processing (DSP design)
** Improve noise suppression (get rid of musical noise) and residual echo suppression
** Improve packet-loss concealment (PLC)
** Re-write the built-in voice activity detector (VAD)
** Improve the 2.15 kbps vocoder mode (there are even 4 unused bits left to use)
** Algorithmic optimizations (see if some searches can be simplified/approximated)

* Complete fixed-point (DSP development)
** Wideband
** VBR
** Rest of the narrowband modes
** Preprocessor (noise suppression, AGC)
** Jitter buffer
** Arch-specific optimization
** More...

* Tune (playing with parameters)
** Noise weighting filter
** Perceptual enhancement

* Features (plain C programming)
** Implement maximum VBR bit-rate
** Implement peeling (write functions to strip some of the bits)
*** Peel high-band (wideband -> narrowband)
*** Transform 24.6 kbps mode to 15 kbps mode

* Documentation
** Use questions from the mailing list to create a better FAQ on the wiki
** Update the Speex manual based on recent papers
** Improve libspeex documentation
** Write good example code

== External links ==

* [[Wikipedia: Speex]]

XiphWiki:Sandbox

2006-07-06T05:16:04Z

Tbullock: Restored after Vandalism

= Headline 1 =
foo
== Headline 2 ==
=== Headline 3 ===
=== Headline 4 ===
{| border=2 cellpadding=10
|+ '''Table test'''
| x || 'One' || ''Two2'' || '''Three'''
|-
! what is this
| 'yes'
| ''no''
! maybe
|-
!
{| border=1 cellpadding =2
|+ for you
| a
| b
| c
|-
| d || e|| f
|}
| 1 || 2 || 3
|}

This is a good test

== Headline 5 ==

* Item 1
* Item 2
* Item 3

LoSSSSSSSSSSSSSSSSSSSSSSSSSSSSSStus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.

It has been reported that links to ".com" sites don't work: [http://www.vorbis.com/ Vorbis Website]

== Headline 2 ==
Good goodess, don't you hate wiki spam?

== Headline 3 ==
It seems that [[Talk:Sandbox]] is the canonical way to link to [[Talk:Sandbox|Talk]].

Fun with tables and templates.
{{PlayersTableHeader|ManufacturerLink=[http://www.iaudio.com iAudio]}}
{{PlayersTableBody|Model=G3|MemType=Flash (builtin)
|MemSize=256MB, 512MB, 1GB
|UMS=Yes
|NeedUpd=NA
|Power=AA battery
|LineIn=Yes
|Mic=Yes
|Radio=Yes
|Formats= MP3, MP2, Ogg, WMA, ASF and WAV
|Comments= Very white, available from online retailers in UK
}}
{{PlayersTableFooter}}

XiphWiki talk:Sandbox

2006-07-06T05:06:59Z

Tbullock: Restored after Vandalism

need an existing talk page to try something... [[User:Imalone|Imalone]]

Libshout

2006-07-06T05:04:21Z

Tbullock: Restored after Vandalism

== Development ==

new features in libshout trunk
*multi-codec Ogg support
*a non-blocking API

whats the remaining diffrence between libshout-kh and libshout?

IceS

2006-07-06T05:02:23Z

Tbullock: Restored after Vandalism

== Stable Releases ==
[http://www.icecast.org/ices.php Ices Website]

Ices comes in two flavors,
* 0.x flavor which supports sending an MP3 stream to an icecast server
* 2.x flavor which supports sending an Ogg Vorbis stream to an icecast server.

== Development ==

=== ices0 ===
for the latest version of ices0 hav a look in the svn repository at http://svn.xiph.org/icecast/trunk/ices0/

=== ices2 ===
development of ices2 is split up into two branches right now.

* http://svn.xiph.org/icecast/trunk/ices here you find the latest version of the ices2.0 release
* http://svn.xiph.org/icecast/branches/kh/ices the kh branche of ices2 as several new features and depends on a [[http://svn.xiph.org/icecast/branches/kh/libshout modified version of libshout]].

one of the new features in ices2-kh is a new input plugin for [http://jackit.sf.net jack]. this way you can send a live ogg vorbis stream from any jack capable audio application.

[http://ices.reboot.fm/ some notes on using ices2 with jack]

IceShare

2006-07-06T05:01:31Z

Tbullock: Restored after Vandalism

{{draft}}

== Help Wanted ==
Just to preceed all this info on what IceShare is, I'd like to make a request to help get it finished sooner. We (Xiph foundation) could really use some help from people with one or more of the following skills:

* Technical documents writer (for libraries, protocols, etc)
* Crypto guru - the IceShare system needs some help with hashing and encryption in general
* Python programmers - to help complete the prototype suite
* Player integration - getting this system available to users

Please contact Arc <arc@Xiph.org> if you can help. Thanks!

== What is it? ==

IceShare is library that distributes Ogg streams on a pseudo-P2P network. It is heavily based on BitTorrent, but works on the Ogg page level, and unlike PeerCast it works with files as well as continuous streams.

It's designed to allow musicians, video producers, radio and television stations, or anyone looking to inexpensivly distribute audio/video on the web. It's intended to be initiated from websites, with links to icet:// URLs. It is not designed for P2P searching, such as Gnutella, Kazaa, and eDonkey provide, however websites may be setup to easily search content on one or more IceTracker servers.

== Overview ==

IceShare is called pseudo-P2P because the network relies on a traditional client-server model for managing transfers between IceShare peers on the network.

The media players are the level which P2P takes place, whereas listeners who have available upstream bandwidth can help distribute the same content they're listening to amoung other listeners. This helps Icecast servers non-linearly scale for much larger listener loads and reduces the bandwidth requirements for hosting static Ogg multimedia on websites.

The IceShare library allows these features to be easily added to media players, including support for seeking to "not downloaded yet" parts of the media and available bandwidth detection/reporting for multi-bitrate streams.

IceTracker is a server that keeps track of who's actively sharing certain media and each of their send/receive ratios. IceTracker helps direct IceShare users to better hosts and track individual user's bandwidth and level of participation to reward high bandwidth/participation users with faster peers. IceTracker servers track users anonymously by a DSA key generated by each IceShare client.

Icecast connects to an IceTracker as a client to provide live stream information (pageno's, checksums, etc) and to receive guidance as per dropping less participating listeners when bandwidth is tight.

== Media Players ==

URLs in the form icet://<icetracker>:<port>/<media> direct the media player to connect to an IceTracker using IceT protocol via the IceShare library. IceShare will state that it need's the specified media.

The IceTracker for that media should then respond with general information about the media in question, how many pages it has, how long its playtime is (or if it is continuous), and generally how long it should take to transfer it. This information should allow the media player to setup the seek bar and know how much it should buffer before beginning play.

IceTracker should then start directing IceShare to hosts which pieces of the media can be accessed from. IceShare does not know how much of the media each of those hosts has, since many may have only partial transfers. IceTracker specifies which page, or set of pages, to download from each host. IceShare responds with a quick "I got it" for each page, thereby letting IceTracker know that the reported page is ready to be shared with others. This also helps IceTracker keep track of latency and bandwidth between peers so that it can provide the client with better hosts.

If the player seeks to an not-yet-downloaded part of the media IceShare can express this to IceTracker, which will change its transfer focus to the seek point and beyond. In this way, especially for long pieces of media, the whole file does not have to be transfered to access a specific section of it.

IceShare also provides media players access to its "page table". The media player can use this to reflect media transfer stats in the seek bar, prehaps using an alternative background color to indicate sections of the media which have been downloaded.

IceShare handles incoming <A HREF="IceHTTP">HTTP</A> connections from peers, information about uploads on the P2P network are available to the media player but are not nessesary. The media player can tune the level of participation, limiting the amount of bandwidth or length of time a piece of media is available. For the most part, it's in the user's interest to participate as much as they're able to, since this will earn them faster access to other media through the same IceTracker.

A slightly-extended <A HREF="IceHTTP">HTTP/1.1</A> is used to specify page-ranges. IceShare should also support byte-ranges for traditional HTTP download agents which are attempting to resume a lost transfer.

== Media Distributors ==

IceShare can also be used to distribute original media on the P2P network. A distribution client can use IceShare to connect to an IceTracker and inform it of the new media's statistics. This client should have enough upstream bandwidth to send the first few copies by itself, after which those who have downloaded it should begin sharing the load.

Icecast is a good example of a distribution client. It can use IceShare to inform IceTracker of its streams and continue to send it page information for each of its ongoing streams. Icecast servers using IceShare will still need enough bandwidth to send atleast one (preferably more) streams to listeners who can then redistribute it to other listeners.

IceTracker will allow IceShare clients to request current listeners and total "hits" for any media that it is tracking. This can be used by Icecast to accurately track listeners.

== Alternative Streams ==

IceShare also includes support for alternative bitrates and codecs to published media. These alternatives can be used to meet the needs of each individual user on the network. For instance, a stream could be provided in 64kbps Vorbis, 24kbps Speex, and 24kbps Vorbis (in that order). Those with enough bandwidth will receive the default 64kbps Vorbis stream, while modem users will switch to either the Speex or the low bitrate Vorbis based on their ability to support Speex. This makes it possible for every IceShare peer to receive a continuous stream in the highest quality format their software and network connection allows them.

== Payload Protocols ==

One of the interesting things about IceShare is that it's designed to use many different protocols for the actual file transfer. This allows a combination of protocols to be used, even in between the same two hosts, in the effort to get the media deployed in the most efficient manner possible.

This also allows IceShare to be combined with other P2P systems. For instance, if someone chose to ignore PeerCast's GPL license addendum which doesn't allow modified clients to connect to their metaserver, a broadcaster could choose to stream to both Peercast and IceShare whereas any IceShare peer with a Peercast plugin could be sent to grab parts or all of the stream from that P2P network. The same is also true for BitTorrent, Gnutella, or any other P2P system.

Here are the requirements for an IceShare Payload Protocol:
* You must be able to request a path (local URL) for a media
** Each media must be at the same path for every protocol
** Local media path sorting and arranging is up to the local implementation
*** All media may be in one directory or many, even layers deep
*** Media may be moved locally (after notifying the Tracker)
* You must be able to specify a range of data for download
** Protocols supporting only Byte ranges limits it's useage
*** A peer may not nessesarily know where in a given binary stream a series of pages belong
*** Byte ranges are only known for pages in a continuous series from the start of the media
** Time ranges are more useable, but may result in wasted bandwidth
** Supporting (Ogg) Page ranges allows total useability
** Range can be requested in any way nessesary for the protocol
*** Some payload protocols may even append it to the media's path
* Binary data must be able to be transfered by some means
** Ogg Pages do not need to be seperated in this data
*** libogg2 provides a fast and efficient manner for seperating Pages by the receiver
** Delivery of any segment does not need to be guarenteed
*** The IceTracker will make sure everyone gets a specific Page
*** Retransmittial by IceTracker is only supported with Page granularity
** Error detection does not need to be implemented
*** Each Ogg Page has it's own CRC checksum in it's header
** Order '' should '' be guarenteed for data within a single Ogg Page
*** Ogg Pages may be sent complete in a single packet for this
*** Many packets may carry sequential Pages with packet ordering provided in a small header
* The IceTracker does not need to know any details of a payload protocol
** It will learn new protocol names when support is advertised by peers
** It will learn their strengths and weaknesses by building statistical data
** Protocols will be used based on the bandwidth, reliability, and timing needs of a peer

== Security Model ==

Three layers of "security" are provided by the IceShare system to ensure data is transfered without errors, without alteration by peers, and without alteration of trusted content from trackers.

== What's the Holdup? ==

While we're apparently fairly close to wrapping up this baby and start into some massive plugin coding, there's vital things missing from other Xiph projects which this needs.

Specifically:
* <strike>OggFile</strike> [[OggStream]] granule handling needs to be decided on so we can get the IceT timing specs to match
* <strike>we need to get the final scoop on discontinuous bitstreams</strike> done and integrated into libogg2
* a fully functional public tracker needs to be written (even if it's just in Python for now).
* it makes alot of sense for the plugins to be packaged with <strike>OggFile</strike> OggStream as a join distribution effort.

Current estimates, given the committments from various Xiph developers and pace of development, is IceShare will begin getting deployed summer <strike>2004</strike> 2005.

''' Updated: 1/10/05 ''' -- I've had to delay IceShare in order to get [[OggStream]] (formerly OggFile) ready. This explains why this project is so over-due.

If you're reading this page and thinking "damned, that's awesome!" and want to speed up the above timeline we can always use volunteers. Even if you don't know any code, but prehaps you're good at HTML or graphic design, or can do no more than help test the system, we could use your help. Email Arc <arc@xiph.org> for more information.

== Discussion ==
Discussion has been moved to the Talk page to keep load times down. Please add comments to [[Talk:IceShare]].

Talk:IceShare

2006-07-06T05:00:06Z

Tbullock: Restored after Vandalism

Iceshare, Peercast or Alluvium?

three answers to the bandwidth problem for grass-roots broadcasting.
Peercast works, now, but it's a relaying system so is only as good as the weakest link in the relay chain and latency builds up as it scales.
Apparently Alluvium works too, but only for Windows clients so I can't test it.
Iceshare is vapourware, but it's conceptually the coolest.

All three will require new users to download and install client software - either a player or a plugin - until the protocols are incorporated out of the box into mainstream vendors' products.

How far apart are Alluvium and Iceshare? Could they be merged?

(edited to add:)Errr... apparently Alluvium is built on top of Swarmcast, which is a proprietary technology...

Which leaves iceshare: now just to get the vapour to condense.

in response to Anonymous: 
"IceTracker is a server that keeps track of who's actively sharing certain media and each of their send/receive ratios. IceTracker helps direct IceShare users to better hosts and track individual user's bandwidth and level of participation to reward high bandwidth/participation users with faster peers." 

doesn't that mean that IceShare does rely on a central server? at least central to the stream? or am i getting things wrong here?

[[User:Stellaris|Stellaris]] 04:34, 9 Aug 2005 (PDT)
 

Act Lab TV -- Phobos - 2005/7 

One of the Co-Developers of Freenet [http://www.freenetproject.org www.freenetproject.org], Brandon Wiley, has released a open source set of tools for swarm streaming media content. [http://actlab.tv actlab.tv] No external tracker software is required and there are no limitations as to the type of media codecs that can be streamed using this software.

. --Anonymous 
As far as I can tell.... IceShare is better than Peercast for a number of reasons.

Firstly, IceShare doesn't depend on a central server. Peercast depends on yp.peercast.org in order to function properly. Yes this is true, and recently peercast has become organised this way. Which i dislike.

Secondly, Peercast requires that you run the peercast client on each machine. If IceShare will be a library then lots of media players will be able to simply "play" a stream. People will just need a player that can do icet://

Thirdly, IceShare is based on ogg. If you look at [http://yp.peercast.org yp.peercast.org] you will find lots of formats. Most of the streams are not using open codecs. For example the video streams, there is just ONE theora stream, while the rest are WMV/NSV.

NSV is a open standard media container format, NOT a video codec
[http://ultravox.aol.com/NSVFormat.rtf Nullsoft Video (NSV) Format Specification - RTF document]

... --2003/11/21 13:36 EST 
yo xiph: quit doing so much cool stuff, you make me feel worthless.

Killer app? --2003/11/22 14:06 EST 
I can't see any competition :D

re: Killer app? --2003/11/28 18:39 EST 
take a look at peercast http://www.peercast.org/ (be shure to disable ECN ;) )
it's working already!

keep the work going!

Wow, wow, wow! --2003/12/01 21:04 EST 
Wow,
I was talking to my Bro about this idea a few months ago, and how it could change the world. I was talking about video, but Audio is a good start!

It will do video. --ArcRiley, 2003/12/10 01:52 EST 
IceShare will work for any Ogg codec, including Theora. In fact that's one of the uses I intend to test it with.

hmm --BlindWanderer, 2004/01/05 10:47 EST 
Swarming streaming would work but i don't think it would catch on. But it still should be made. It would help guarantee freedom of speech/press in this world of censorship.

... --2004/01/12 01:33 EST 
Video might end up being the killer app. Hosting an audio stream is expensive, it is still feasible. Hosting a video stream, on the other hand, rapidly becomes unaffordable. This project could make it affordable to broadcast high-quality video streams to a large audience

Where's the download link? --2004/01/19 22:35 EST 
?????????????????????

Work in progress --ArcRiley, 2004/02/04 08:25 EST 
This is currently in the "pre-alpha experimental and design" phase. We have
some software, mostly for testing, and the protocols are still being altered
slightly or extended as we need to. Don't worry, we'll make a big media
splash if/when we get to beta release phase.

... --2004/01/21 22:38 EST 
will it be posible to listen to a radio with winamp?, i mean no need for a special player?
how coul we broadcast? using a special program?

Winamp --ArcRiley, 2004/02/04 08:27 EST 
Short answer; when someone writes the software for this, and then only after
we've finalised the spec. WinAMP will need a plugin, but that is all. The
intention of IceShare is for it to be integrated closely with the media player,
so not only should icet:// links open your media player directly, but things
such as seeking should work seamlessly. As for broadcasting software,
that's left completely up to implementation. Icecast support should be
written eventually so any standard Icecast2 server can be used, but anyone
could write a direct IceShare streaming client. Let's focus less on vaporware,
right now we're concentrating on the spec, not integration with media players.

local relay --Andy Baxter, Sept 2004 
Seeing as it might take a while for plugins to be written for all the players, how about making a local relay program for the main platforms which uses the iceshare library to provide a local http or rtsp relay, which players can connect to? This would also do as a reference implementation of the library for plugin coders. If the right protocol was used, it could handle seeking etc as well.

misinformation --2004/03/01 11:17 EST 
I think you may have been misinformed about PeerCast, we're using it as the core of our media player and are streaming static files with it. Security was a concern for us so we added a very simple SKEY signature to broadcast packets that allows clients to verify each packet has not been modified. Although we haven't submitted patches to the PeerCast developers yet. Also our client is "allowed" to connect o to the main PeerCast network, in fact the developers have been very eager for us to do that.

Conferencing --AlexanderWinston, 2004-03-03 00:00 UTC 
Might this have possible tele- or videoconferencing uses?

Dead Project --2004/11/09 
Was a great idea, too bad it never took off.

Don't Assume -- 2004/11/19 
The wiki just hasn't been maintained, work is happening behind the scenes. Be patient.

2004/11/19
I am very glad to hear this news! I am looking for something just like this & this looks very promising. I have started an internet radio station and am looking for a way to expand the stream once the audience exceeds my server capacity.

I know nothing of writing code but could beta test or write a "how to" article.

Peercast & IceShare - [mailto:zephyrxero@yahoo.com ZephyrXero] - 2005/1/7 
I've been wishing for a project like this for about a year now. I just discovered Peercast the other day, and now this. I'll be very excited to see where the IceShare/IceTracker stuff goes. I've been in love with everything ogg since I found out about it.
 
My question is, since IceShare & Peercast are open source projects... do you plan to share code from each other? What kind of collaboration has happened, if any...so far? Can't wait for the beta of IS to be released. I see huge potential for P2P streaming a/v in the near future.

Re: Peercast & IceShare - Arc 2005/1/10 
I'm not sure how code sharing would help us. The systems are radically different in both theory and implementation.

Mostly what we need, at this point, is to finish hashing out the details on the hash functions (ok, a little pun intended) and the anonymous identity challenge, and to get libogg2/OggStream to the point where all this stuff is seamlessly useable.

== Iceshare vs peercast ==

I recently set up a little peercast network on a trial basis. Everyone has UK-standard ADSL/RADSL connections which are uncapped 512/256 kbit/s with 50:1 contention. The source stream is a 64kbps Ogg/icecast stream (actual rates vary, of course).

Performance has been very variable, with many users reporting long interruptions as it pre-buffers, but not consistently. I haven't been able to identify the problem although my instinct is that it is caused by bandwidth contention; the popularity of BitTorrent means that the typical spiky email-websurfing bandwidth usage pattern which informed the 50:1 contention architecture of DSL systems no longer applies - although whenever I test the bandwidth available to me I get a figure in the high 400's.

As I understand Peercast, with its relay architecture, anyone in the chain suffering this problem will cause difficulties for those further down the line (please correct me if I'm wrong, I often am). Thus popularity doesn't increase the available bandwidth, it just doesn't reduce it as direct streaming does. It seems to me that the BitTorrent - swarming approach will scale much better than peercast; at least I'm hoping..

'''-Peercast experiences - ZephyrXero - 2005/2/6'''

I've been running a [http://penguin.agrid.usm.edu/~deisenhardt/radio peercast radio station] for almost a month now and have had varying results as well. Some days it runs silky smooth while other days I can't listen for more than 10 min. before it times out. If peercast used a swarming technique for it's sharing it would work much better than just relying on each user to give a full stream up to someone else. I really hope that Xiph can get IceShare up and running soon! I also hope my [http://slashdot.org/article.pl?sid=05/01/10/1410232 slashdot article] has helped bring in some new developers and interest in the project :)

2005/8/8 :: Bloke
Pardon my ignorance but shouldnt this packet distribution be hooked on to the current bit torrent network? act like a plugin?

cheers

2006/2/5 :: Is there anyone still working on this? I for one would be glad to help...someone drop me an email.
[[User:Steve132|Steve132]]

Talk:Games that use Vorbis

2006-07-06T04:59:11Z

Tbullock: Restored after Vandalism

* I'm a beta tester (for Savage) has this been added yet? I still see quite a few .wav's (trelane)
* Yes, those are sound effects. Vorbis is only used for music, because you wouldn't want to burden the CPU with decoding 24 oggs simultaneously (slothy).
* Of course you could decode the sound samples ahead of time and avoid the decode on the fly silliness. (xcaliber)
*At the expense of load time slowness if you do it then, or install time slowness if you do it during the install. If you do it during the install, you've only saved yourself space on the CD, which you can probably do in other ways as well. Plus most games don't keep all the sounds loaded in memory, so decompressing them to memory isn't a good thing, it's a RAM hog. This is why nobody should use any compressed codecs for sound effects in games. (slothy)
* Doesn't the PC version of GTA San Andreas Use Vorbis?
* It seems like Black and White 2 by Lionhead uses Ogg Vorbis.

FishFaq

2006-07-06T04:57:48Z

Tbullock: Restored after Vandalism

This page combines questions related to all Xiph projects.

== General Ogg questions ==

=== What is a granulepos ? ===

A granulepos is a representation for a timestamp on a scale specific to the codec. Conrad Parker clarifies the definition of granulepos as "representing the presentation time for the last presentable data item in an Ogg packet."

=== Where is the granulepos stored in the bitstream ? ===

=== How does the Ogg packet number work ? ===

The Ogg bitstream does not store packet numbers in the bitstream. Only page sequence numbers are
stored. libogg will count packets and give each Ogg packet a packet number. Normally these are
in sequence; when Ogg notices a discontinuity however (page sequence numbers don't match up (FIXME: is this actually in the code ?), or
the lacing values don't match up) it will increment the page counter by 1, which thus shows up as a missing packet (see http://trac.xiph.org/cgi-bin/trac.cgi/file/trunk/ogg/src/framing.c, _packetout()).

== Player implementation questions ==

=== What use cases do I need to consider when writing a player ? ===

There are different ways in which an ogg stream reaches your player. Each of these ways has some specific restrictions and potential problems that your player needs to be able to deal with. These are:

- the "ideal" case: a correctly muxed Ogg stream as a seekable file, with correct bos packets, header packets, and eos packets, time-correct muxing, and a continuous set of Ogg pages
- the "lossless streaming" case (e.g. HTTP streaming): you receive correct bos and header packets, and a string of Ogg packets in pages that are continuous, but start with a discontinuity. The stream might or might not be seekable, and you do not get eos pages
- the "saved from lossless streaming" case: as above, but you can seek. You still don't have eos pages
- the "lossy streaming" case (e.g. RTP streaming): some of the Ogg pages get lost in transmission. In the case of RTP, you actually may have less, or different, information to go on, since it is recommended that RTP packetizing is used instead of Ogg packetizing. An HTTP stream could also be lossy, if the server for example decides that the client is not reading fast enough and drops a set of intermediary buffers.
- the "no feedback" case (e.g. satellite broadcasts): there is no way for the client to communicate with the server. The client needs to get the header pages through other means, and then interpret the Ogg stream it receives.

Bounties

2006-07-06T04:55:56Z

Tbullock: Restored after Vandalism

These are proposed bounty projects, similar to http://gnome.org/bounties/
or the [http://ghostscript.com/article/58.html Ghostscript bug bounty] program.
We don't have the same level of funding but could start a pot with $10-$100 and
let people contribute to specific bounties through paypal.

It would be helpful to list $ amounts which have been donated for each bounty, even if the foundation hasn't decided how much extra (if any) to allocate. --Tesseract

=== OggVorbis 5.1 ===
5.1 Sound encoding in Ogg Vorbis.

There are two steps here. Simple coupling and lowpass for the .1 channel, and a full set of tuned modes.
They should be separate bounties.

:This should be implemented with ambisonics as the internally coupled channels, and then use ambisonic g-format filters for en/dec coding from and to 5.1. This will allow correct playback on many different speaker layouts and an easy path to headphone support.

=== Xiph Quicktime Plugin ===
[http://www.xiph.org/quicktime/ QuickTime Components] is now a project hosted on xiph.org.

You have to write a Quicktime Plugin for the Ogg container and the Xiph Codec Family.
[http://qtcomponents.sf.net qtcomponents] provides support for Ogg Vorbis and MNG. This could be used as start.
Xiph Quicktime Plugin has to support encoding/decoding for:
* Ogg Media container
**[http://qtcomponents.sf.net qtcomponents] ''has an operational pluggable API for import, it needs some work to be long term supportable. It does not have a pluggable API for exporting at this time.''
* Support for Chained Ogg Streams
**[http://qtcomponents.sf.net qtcomponents] ''imports chained files as multiple tracks in QuickTime. It does not create chained files during export.''
* Support for Icecast Streams (sending is optional)
**[http://qtcomponents.sf.net qtcomponents] ''implements nothing towards this item. First up is a reverse-engineering effort, as the specifications for a streaming media handler have not been published.''
* Support for Xiph Codec Family: Vorbis, Theora, FLAC, Speex, Writ
**[http://qtcomponents.sf.net qtcomponents] ''has code for Vorbis and Speex (not working at the moment) and there is code at [http://damien.drix.free.fr/qtflac/ Damien Drix's site] for FLAC (decode only).''
It must also be possible to use the Xiph codecs in .mov files in combination with other quicktime codecs.
*[http://qtcomponents.sf.net qtcomponents] ''supports embedding media encoded with Xiph codes into .mov files.''
The plugin should work with at least QuickTime 6.x and 7.x on Mac OS X and Windows. (Mac OS 9 would be nice but probably isn't as important.)

All work must be released under the GPL.

=== Aggressive low-bitrate libvorbis encoding improvements for Vorbis I ===
libvorbis has a lot of room for improvement in all quality/bitrate departments, particularly at the lower quality levels / bitrates. There are many directions to approach this problem from.
To claim this bounty, the following criteria would have to be met:
* A 25%-or-better reduction in bitrate for quality levels -1, 0, 1 on a reasonable testsuite while maintaining qualitative equivilence (or improvement) in community testing.
* No overall qualitative/bitrate regressions in quality levels 2 upwards
* Output ogg files compatible with Vorbis I spec
* Changes under suitable license for re-integration with Xiph.Org libvorbis

=== iPod playback support ===
The [http://ipodlinux.sourceforge.net/ Linux on iPod] project has vorbis decode working (with alternate firmware) at a good fraction of realtime. It should be a small matter of optimization to get it working
for useful playback.

=== FLAC support in libfishsound ===
[http://annodex.net/software/libfishsound/ libfishsound] currently only supports Ogg Vorbis and Ogg Speex. It should be extended to support FLAC to complete the set of Xiph audio codecs.

=== Ogg Vorbis Bitrate Peeling ===
:Note: a bounty for this project has been posted on [https://launchpad.net/ launchpad.net]: [https://launchpad.net/bounties/ogg-vorbis-bitrate-peeling Add bitrate peeling to the standard libvorbis encoding library].
Ogg Vorbis bitrate peeling has been a topic brought up time and again to combat MP3 enthusiasts. But this feature does not actually exist, only the mere possibility abounds. This bounty is set to change that.
The peeler must meet the following criteria:
* Any Vorbis stream can be converted (not transcoded) to a lower quality setting
* Resulting streams would be identical or nearly identical to a stream generated by encoding the original source to the selected quality
* This process is reasonably fast (that is, signifigantly faster than re-encoding from source)
The following must also be accomplished to claim this bounty:
* The encoding libraries must be updated to create peelable Vorbis streams natively
* Old Vorbis streams must be peelable already, or convertable with a utility in order to be made peelable
* If older streams are not natively peelable, old unpeelable Vorbis streams must be identifiable and discernable from peelable streams in such a way as to facilitate transcoding streams from the old format
* All work submitted must be licenced under a BSD style licence (excepting circumstances where other licences may conflict)

Talk:Auto

2006-07-06T04:51:00Z

Tbullock: Restored after Vandalism

MonthlyMeeting200509

2006-07-06T04:48:48Z

Tbullock: Restored After Spam

== Time ==

This meeting will be held at 18h00 GMT September 7, 2005, in #xiphmeet on irc.freenode.net.

<center>'''Note the new time!'''</center>

== Agenda ==

# Project reports
# New releases for vorbis, icecast?
# New website progress
# Optimalizations (theora)
# On demand encoding/streaming (ices/icecast)
# Multiple volunteers to get ogg bitrate peeling off the ground

MonthlyMeeting200511

2006-07-06T04:48:11Z

Tbullock: Restored after vandalism

== Agenda ==

* Get someone to go to the next IETF meeting (there's a Speex draft submitted)

Talk:Autoversicherung

2006-07-06T04:47:11Z

Tbullock: Removed Spam

Talk:MonthlyMeeting200509

2006-07-06T04:44:30Z

Tbullock: Removed Spam

Talk:MonthlyMeeting200511

2006-07-06T04:43:10Z

Tbullock: Removed Spam

Theora

2006-07-06T04:40:04Z

Tbullock: Restored page after vandalism

'''Theora''' is our video codec, based on the [[VP3]] codec donated by [[On2 Technologies]]. We've refined and extended it, giving it the same future scope for encoder improvement [[Vorbis]] has. See http://theora.org/ for more information.

== Features ==

Features available in the Theora format (and a comparison to VP3 and MPEG-4 ASP):

* block-based motion compensation
* 8x8 Type-II Discrete Cosine Transform
* free-form variable bit rates (VBR)
* adaptive in-loop deblocking applied to the edges of the coded blocks (not existing in MPEG-4 ASP)
* block sizes down to 8x8 (MPEG-4 ASP supports 8x8 only with 4MV)
* 384 8x8 custom quantization matrices: intra/inter, luma/chroma and even each quant (more than VP3 and MPEG-4 ASP/AVC)
* flexible entropy encoding (Theora supports 80 VLC tables selectable per-frame, MPEG-4 ASP has just one)
* 4:2:0, 4:2:2, and 4:4:4 chroma subsampling formats (VP3 and MPEG-4 ASP only support 4:2:0)
* 8 bits per pixel per color channel
* multiple reference frames (not possible in MPEG-4 ASP)
* pixel aspect ratio (eg for anamorphic signalling/playback)
* non-multiple of 16 picture sizes (as possible in ASP, but not in VP3)
* non-linear scaling of quants values (as done in MPEG-4 AVC)
* adaptive quantisation down to the block level (as possible in MPEG-4 ASP/AVC, but not in VP3)
* intra frames (I-Frames in MPEG), inter frames (P-Frames), but no B-Frames (as supported in MPEG-4 ASP/AVC)
* HalfPixel Motion Search Precision (MPEG-4 ASP/AVC supports HalfPixel or QuarterPixel)
* technologies used already in Vorbis (decoder setup configuration, bitstream headers...) not available in VP3

Note that not all of these features are already implemented in the reference encoder/decoder.

== Status ==
* Alpha 7 is the latest stable release.
* The bitstream format was frozen in Theora alpha 3: every file created with this encoder (and, of course, later encoders) will be playable by any compliant Theora decoder.

== Development ==

* [[Theora:Beta1ToDo|Todo for Beta1]]

== More information ==

* [[TheoraHardware]]: List of hardware-players supporting Ogg Theora
* [[TheoraSoftwarePlayers]]: List of media players that can play Ogg Theora
* [[TheoraSoftwareEncoders]]: List of software that can encode to Ogg Theora
* [[TheoraDecoders]]: List of decoder implementations
* [[TheoraEncoders]]: List of encoder implementations
* [[List of Theora videos]]: Get some files to see what the codec's like

== External links ==

* [http://www.theora.org/ Theora homepage]
* [http://www.annodex.net/software/theora/ Theora documentation daily builds]
* [[Wikipedia: Theora]]
* [http://www.vp3.com VP3 homepage]: The homepage of the codec Theora is based on
* [http://www.on2.com On2 Technologies]: The authors of VP3
* [http://forum.doom9.org/showthread.php?s=&threadid=77314 Ogg Theora Information on Doom9 Forum]
* [http://www.parrishtech.com/content/view/16/1/ HOWTO: Rip DVD to Theora using Linux]
* [http://www.doom9.org/index.html?/codecs-quali-105-1.htm Codec shoot-out 2005] Comparison of many video codec, including theora

Talk:Theora

2006-07-06T04:37:17Z

Tbullock: Removed Vandalism

Removed Spam