https://wiki.xiph.org/api.php?action=feedcontributions&user=Rillian&feedformat=atomXiphWiki - User contributions [en]2024-03-29T00:19:33ZUser contributionsMediaWiki 1.40.1https://wiki.xiph.org/index.php?title=XiphInfra:Overview&diff=16703XiphInfra:Overview2020-05-16T16:20:08Z<p>Rillian: Add developer category so the page is easier to find.</p>
<hr />
<div>This Namespace is used to group everything related to Xiph infrastructure. It aims to provide information about the services<br />
in use by Xiph and on which server each of them is hosted.<br />
<br />
== List of services ==<br />
Below is a list of all services, if anything is missing, add it to the [[XiphInfra:List of services|List of services page]].<br />
{{XiphInfra:List of services}}<br />
<br />
[[Category:Developers stuff]]</div>Rillianhttps://wiki.xiph.org/index.php?title=XiphInfra:List_of_services&diff=16702XiphInfra:List of services2020-03-07T16:28:41Z<p>Rillian: Update maintainer list</p>
<hr />
<div>{|class="wikitable sortable"<br />
! Service<br />
! URL<br />
! VM<br />
! Host<br />
! Maintainer(s)<br />
|-<br />
| [[AreWeCompressedYet]]<br />
| style="text-align:right;"| https://arewecompressedyet.com<br />
| awcy<br />
| style="text-align:right;"| catfish<br />
| TD-Linux<br />
|-<br />
| Git Repos<br />
| style="text-align:right;"| https://git.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| ePirat, rillian<br />
|-<br />
| Home Pages<br />
| style="text-align:right;"| https://people.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| <br />
|-<br />
| [[Icecast]] Streams<br />
| style="text-align:right;"| http://dir.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| tbr<br />
|-<br />
| [[Icecast]] Streams (Beta)<br />
| style="text-align:right;"| http://dir-test.xiph.org<br />
| <br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| Jenkins<br />
| style="text-align:right;"| https://mf4.xiph.org/jenkins/<br />
| jenkins<br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| Mail<br />
| style="text-align:right;"| xiph.org<br />
| mailfish<br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| MailMan<br />
| style="text-align:right;"| http://lists.xiph.org<br />
| mailfish<br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| Media<br />
| style="text-align:right;"| https://media.xiph.org<br />
| <br />
| style="text-align:right;"| beaufish<br />
| TD-Linux, rillian<br />
|-<br />
| Opus Boodler Streams<br />
| style="text-align:right;"| https://opus-codec.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| gmaxwell<br />
|-<br />
| Rietveld<br />
| style="text-align:right;"| https://review.xiph.org<br />
| jenkins<br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| Social<br />
| style="text-align:right;"| https://social.xiph.org<br />
| social<br />
| style="text-align:right;"| catfish<br />
| tbr<br />
|-<br />
| Subversion Repos<br />
| style="text-align:right;"| https://svn.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| rillian<br />
|-<br />
| Trac Bug Tracker<br />
| style="text-align:right;"| https://trac.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| tbr<br />
|-<br />
| [[XiphWiki:Features|Wiki]]<br />
| style="text-align:right;"| https://wiki.xiph.org<br />
| [[XiphInfra:Wiki VM|wiki]]<br />
| style="text-align:right;"| catfish<br />
| ePirat<br />
|-<br />
| Xiph Mirror Repos<br />
| style="text-align:right;"| https://github.com/xiph<br />
| <br />
| <br />
| ePirat, rillian<br />
|-<br />
| XiphBot-ng<br />
| style="text-align:right;"| XiphWiki on freenode.net<br />
| <br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| [[XiphInfra:Gitlab|Gitlab]]<br />
| style="text-align:right;"| https://gitlab.xiph.org<br />
| gitlab<br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr, TD-Linux, rillian<br />
|}<br />
<br />
<noinclude>See the [[XiphInfra:Overview|Overview]] page for more information.</noinclude></div>Rillianhttps://wiki.xiph.org/index.php?title=XiphInfra:List_of_services&diff=16701XiphInfra:List of services2020-03-07T16:26:02Z<p>Rillian: Add social vm, allegedly maintained by tbr</p>
<hr />
<div>{|class="wikitable sortable"<br />
! Service<br />
! URL<br />
! VM<br />
! Host<br />
! Maintainer(s)<br />
|-<br />
| [[AreWeCompressedYet]]<br />
| style="text-align:right;"| https://arewecompressedyet.com<br />
| awcy<br />
| style="text-align:right;"| catfish<br />
| TD-Linux<br />
|-<br />
| Git Repos<br />
| style="text-align:right;"| https://git.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| rillian<br />
|-<br />
| Home Pages<br />
| style="text-align:right;"| https://people.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| <br />
|-<br />
| [[Icecast]] Streams<br />
| style="text-align:right;"| http://dir.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| tbr<br />
|-<br />
| [[Icecast]] Streams (Beta)<br />
| style="text-align:right;"| http://dir-test.xiph.org<br />
| <br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| Jenkins<br />
| style="text-align:right;"| https://mf4.xiph.org/jenkins/<br />
| jenkins<br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| Mail<br />
| style="text-align:right;"| xiph.org<br />
| mailfish<br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| MailMan<br />
| style="text-align:right;"| http://lists.xiph.org<br />
| mailfish<br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| Media<br />
| style="text-align:right;"| https://media.xiph.org<br />
| <br />
| style="text-align:right;"| beaufish<br />
| TD-Linux<br />
|-<br />
| Opus Boodler Streams<br />
| style="text-align:right;"| https://opus-codec.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| gmaxwell<br />
|-<br />
| Rietveld<br />
| style="text-align:right;"| https://review.xiph.org<br />
| jenkins<br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| Social<br />
| style="text-align:right;"| https://social.xiph.org<br />
| social<br />
| style="text-align:right;"| catfish<br />
| tbr<br />
|-<br />
| Subversion Repos<br />
| style="text-align:right;"| https://svn.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| rillian<br />
|-<br />
| Trac Bug Tracker<br />
| style="text-align:right;"| https://trac.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| tbr<br />
|-<br />
| [[XiphWiki:Features|Wiki]]<br />
| style="text-align:right;"| https://wiki.xiph.org<br />
| [[XiphInfra:Wiki VM|wiki]]<br />
| style="text-align:right;"| catfish<br />
| ePirat<br />
|-<br />
| Xiph Mirror Repos<br />
| style="text-align:right;"| https://github.com/xiph<br />
| <br />
| <br />
| rillian<br />
|-<br />
| XiphBot-ng<br />
| style="text-align:right;"| XiphWiki on freenode.net<br />
| <br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| [[XiphInfra:Gitlab|Gitlab]]<br />
| style="text-align:right;"| https://gitlab.xiph.org<br />
| gitlab<br />
| style="text-align:right;"| catfish<br />
| ePirat (VM and Gitlab), tbr (VM and Gitlab), TD-Linux (Gitlab)<br />
|}<br />
<br />
<noinclude>See the [[XiphInfra:Overview|Overview]] page for more information.</noinclude></div>Rillianhttps://wiki.xiph.org/index.php?title=XiphInfra:List_of_services&diff=16700XiphInfra:List of services2020-03-07T16:22:42Z<p>Rillian: hosts don't need to be urls</p>
<hr />
<div>{|class="wikitable sortable"<br />
! Service<br />
! URL<br />
! VM<br />
! Host<br />
! Maintainer(s)<br />
|-<br />
| [[AreWeCompressedYet]]<br />
| style="text-align:right;"| https://arewecompressedyet.com<br />
| awcy<br />
| style="text-align:right;"| catfish<br />
| TD-Linux<br />
|-<br />
| Git Repos<br />
| style="text-align:right;"| https://git.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| rillian<br />
|-<br />
| Home Pages<br />
| style="text-align:right;"| https://people.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| <br />
|-<br />
| [[Icecast]] Streams<br />
| style="text-align:right;"| http://dir.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| tbr<br />
|-<br />
| [[Icecast]] Streams (Beta)<br />
| style="text-align:right;"| http://dir-test.xiph.org<br />
| <br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| Jenkins<br />
| style="text-align:right;"| https://mf4.xiph.org/jenkins/<br />
| jenkins<br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| Mail<br />
| style="text-align:right;"| xiph.org<br />
| mailfish<br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| MailMan<br />
| style="text-align:right;"| http://lists.xiph.org<br />
| mailfish<br />
| style="text-align:right;"| catfish<br />
| ePirat, tbr<br />
|-<br />
| Media<br />
| style="text-align:right;"| https://media.xiph.org<br />
| <br />
| style="text-align:right;"| beaufish<br />
| TD-Linux<br />
|-<br />
| Opus Boodler Streams<br />
| style="text-align:right;"| https://opus-codec.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| gmaxwell<br />
|-<br />
| Rietveld<br />
| style="text-align:right;"| https://review.xiph.org<br />
| jenkins<br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| Subversion Repos<br />
| style="text-align:right;"| https://svn.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| rillian<br />
|-<br />
| Trac Bug Tracker<br />
| style="text-align:right;"| https://trac.xiph.org<br />
| <br />
| style="text-align:right;"| mf4<br />
| tbr<br />
|-<br />
| [[XiphWiki:Features|Wiki]]<br />
| style="text-align:right;"| https://wiki.xiph.org<br />
| [[XiphInfra:Wiki VM|wiki]]<br />
| style="text-align:right;"| catfish<br />
| ePirat<br />
|-<br />
| Xiph Mirror Repos<br />
| style="text-align:right;"| https://github.com/xiph<br />
| <br />
| <br />
| rillian<br />
|-<br />
| XiphBot-ng<br />
| style="text-align:right;"| XiphWiki on freenode.net<br />
| <br />
| style="text-align:right;"| mf4<br />
| TD-Linux<br />
|-<br />
| [[XiphInfra:Gitlab|Gitlab]]<br />
| style="text-align:right;"| https://gitlab.xiph.org<br />
| gitlab<br />
| style="text-align:right;"| catfish<br />
| ePirat (VM and Gitlab), tbr (VM and Gitlab), TD-Linux (Gitlab)<br />
|}<br />
<br />
<noinclude>See the [[XiphInfra:Overview|Overview]] page for more information.</noinclude></div>Rillianhttps://wiki.xiph.org/index.php?title=XiphInfra:List_of_services&diff=16699XiphInfra:List of services2020-03-07T16:18:44Z<p>Rillian: wiki vm is on catfish</p>
<hr />
<div>{|class="wikitable sortable"<br />
! Service<br />
! URL<br />
! VM<br />
! Host<br />
! Maintainer(s)<br />
|-<br />
| [[AreWeCompressedYet]]<br />
| style="text-align:right;"| https://arewecompressedyet.com<br />
| awcy<br />
| style="text-align:right;"| https://catfish.xiph.org<br />
| TD-Linux<br />
|-<br />
| Git Repos<br />
| style="text-align:right;"| https://git.xiph.org<br />
| <br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| rillian<br />
|-<br />
| Home Pages<br />
| style="text-align:right;"| https://people.xiph.org<br />
| <br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| <br />
|-<br />
| [[Icecast]] Streams<br />
| style="text-align:right;"| http://dir.xiph.org<br />
| <br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| tbr<br />
|-<br />
| [[Icecast]] Streams (Beta)<br />
| style="text-align:right;"| http://dir-test.xiph.org<br />
| <br />
| style="text-align:right;"| https://catfish.xiph.org<br />
| ePirat, tbr<br />
|-<br />
| Jenkins<br />
| style="text-align:right;"| https://mf4.xiph.org/jenkins/<br />
| jenkins<br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| TD-Linux<br />
|-<br />
| Mail<br />
| style="text-align:right;"| xiph.org<br />
| mailfish<br />
| style="text-align:right;"| https://catfish.xiph.org<br />
| ePirat, tbr<br />
|-<br />
| MailMan<br />
| style="text-align:right;"| http://lists.xiph.org<br />
| mailfish<br />
| style="text-align:right;"| https://catfish.xiph.org<br />
| ePirat, tbr<br />
|-<br />
| Media<br />
| style="text-align:right;"| https://media.xiph.org<br />
| <br />
| style="text-align:right;"| https://media.xiph.org<br />
| TD-Linux<br />
|-<br />
| Opus Boodler Streams<br />
| style="text-align:right;"| https://opus-codec.org<br />
| <br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| gmaxwell<br />
|-<br />
| Rietveld<br />
| style="text-align:right;"| https://review.xiph.org<br />
| jenkins<br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| TD-Linux<br />
|-<br />
| Subversion Repos<br />
| style="text-align:right;"| https://svn.xiph.org<br />
| <br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| rillian<br />
|-<br />
| Trac Bug Tracker<br />
| style="text-align:right;"| https://trac.xiph.org<br />
| <br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| tbr<br />
|-<br />
| [[XiphWiki:Features|Wiki]]<br />
| style="text-align:right;"| https://wiki.xiph.org<br />
| [[XiphInfra:Wiki VM|wiki]]<br />
| style="text-align:right;"| https://catfish.xiph.org<br />
| ePirat<br />
|-<br />
| Xiph Mirror Repos<br />
| style="text-align:right;"| https://github.com/xiph<br />
| <br />
| <br />
| rillian<br />
|-<br />
| XiphBot-ng<br />
| style="text-align:right;"| XiphWiki on freenode.net<br />
| <br />
| style="text-align:right;"| https://mf4.xiph.org<br />
| TD-Linux<br />
|-<br />
| [[XiphInfra:Gitlab|Gitlab]]<br />
| style="text-align:right;"| https://gitlab.xiph.org<br />
| gitlab<br />
| style="text-align:right;"| https://catfish.xiph.org<br />
| ePirat (VM and Gitlab), tbr (VM and Gitlab), TD-Linux (Gitlab)<br />
|}<br />
<br />
<noinclude>See the [[XiphInfra:Overview|Overview]] page for more information.</noinclude></div>Rillianhttps://wiki.xiph.org/index.php?title=OpusExtensions&diff=16336OpusExtensions2016-04-19T21:20:31Z<p>Rillian: merge sections</p>
<hr />
<div>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.<br />
<br />
Below is a list of such alternate sequences, to avoid duplication.<br />
<br />
== List of reserved invalid Opus TOC sequences ==<br />
<br />
* `Op` is used as a prefix for metadata headers in .opus files. [https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]<br />
* '0x3FF' in the first 11 bits marks an `opus_control_header` in MPEG-TS. [[OpusTS]]<br />
<br />
== Space of all invalid Opus TOC sequences ==<br />
<br />
* 0x0300<br />
* 0x030C...0x0340<br />
* 0x034C...0x0380<br />
* 0x038C...0x03C0<br />
* 0x03CC...0x03FF<br />
<br />
* 0x0700<br />
* 0x070C...0x0740<br />
* 0x074C...0x0780<br />
* 0x078C...0x07C0<br />
* 0x07CC...0x07FF<br />
<br />
* 0x0B00<br />
* 0x0B06...0x0B40<br />
* 0x0B46...0x0B80<br />
* 0x0B86...0x0BC0<br />
* 0x0BC6...0x0BFF<br />
<br />
* 0x0F00<br />
* 0x0F06...0x0F40<br />
* 0x0F46...0x0F80<br />
* 0x0F86...0x0FC0<br />
* 0x0FC6...0x0FFF<br />
<br />
* 0x1300<br />
* 0x1303...0x1340<br />
* 0x1343...0x1380<br />
* 0x1383...0x13C0<br />
* 0x13C3...0x13FF<br />
<br />
* 0x1700<br />
* 0x1703...0x1740<br />
* 0x1743...0x1780<br />
* 0x1783...0x17C0<br />
* 0x17C3...0x17FF<br />
<br />
* 0x1B00<br />
* 0x1B02...0x1B40<br />
* 0x1B42...0x1B80<br />
* 0x1B82...0x1BC0<br />
* 0x1BC2...0x1BFF<br />
<br />
* 0x1F00<br />
* 0x1F02...0x1F40<br />
* 0x1F42...0x1F80<br />
* 0x1F82...0x1FC0<br />
* 0x1FC2...0x1FFF<br />
<br />
* 0x2300<br />
* 0x230C...0x2340<br />
* 0x234C...0x2380<br />
* 0x238C...0x23C0<br />
* 0x23CC...0x23FF<br />
<br />
* 0x2700<br />
* 0x270C...0x2740<br />
* 0x274C...0x2780<br />
* 0x278C...0x27C0<br />
* 0x27CC...0x27FF<br />
<br />
* 0x2B00<br />
* 0x2B06...0x2B40<br />
* 0x2B46...0x2B80<br />
* 0x2B86...0x2BC0<br />
* 0x2BC6...0x2BFF<br />
<br />
* 0x2F00<br />
* 0x2F06...0x2F40<br />
* 0x2F46...0x2F80<br />
* 0x2F86...0x2FC0<br />
* 0x2FC6...0x2FFF<br />
<br />
* 0x3300<br />
* 0x3303...0x3340<br />
* 0x3343...0x3380<br />
* 0x3383...0x33C0<br />
* 0x33C3...0x33FF<br />
<br />
* 0x3700<br />
* 0x3703...0x3740<br />
* 0x3743...0x3780<br />
* 0x3783...0x37C0<br />
* 0x37C3...0x37FF<br />
<br />
* 0x3B00<br />
* 0x3B02...0x3B40<br />
* 0x3B42...0x3B80<br />
* 0x3B82...0x3BC0<br />
* 0x3BC2...0x3BFF<br />
<br />
* 0x3F00<br />
* 0x3F02...0x3F40<br />
* 0x3F42...0x3F80<br />
* 0x3F82...0x3FC0<br />
* 0x3FC2...0x3FFF<br />
<br />
* 0x4300<br />
* 0x430C...0x4340<br />
* 0x434C...0x4380<br />
* 0x438C...0x43C0<br />
* 0x43CC...0x43FF<br />
<br />
* 0x4700<br />
* 0x470C...0x4740<br />
* 0x474C...0x4780<br />
* 0x478C...0x47C0<br />
* 0x47CC...0x47FF<br />
<br />
* 0x4B00<br />
* 0x4B06...0x4B40<br />
* 0x4B46...0x4B80<br />
* 0x4B86...0x4BC0<br />
* 0x4BC6...0x4BFF<br />
<br />
* 0x4F00<br />
* 0x4F06...0x4F40<br />
* 0x4F46...0x4F6F<br />
* 0x4F70 ("Op"): ID and Comment headers in .opus files [https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]<br />
* 0x4F71...0x4F80<br />
* 0x4F86...0x4FC0<br />
* 0x4FC6...0x4FFF<br />
<br />
* 0x5300<br />
* 0x5303...0x5340<br />
* 0x5343...0x5380<br />
* 0x5383...0x53C0<br />
* 0x53C3...0x53FF<br />
<br />
* 0x5700<br />
* 0x5703...0x5740<br />
* 0x5743...0x5780<br />
* 0x5783...0x57C0<br />
* 0x57C3...0x57FF<br />
<br />
* 0x5B00<br />
* 0x5B02...0x5B40<br />
* 0x5B42...0x5B80<br />
* 0x5B82...0x5BC0<br />
* 0x5BC2...0x5BFF<br />
<br />
* 0x5F00<br />
* 0x5F02...0x5F40<br />
* 0x5F42...0x5F80<br />
* 0x5F82...0x5FC0<br />
* 0x5FC2...0x5FFF<br />
<br />
* 0x6300<br />
* 0x630C...0x6340<br />
* 0x634C...0x6380<br />
* 0x638C...0x63C0<br />
* 0x63CC...0x63FF<br />
<br />
* 0x6700<br />
* 0x670C...0x6740<br />
* 0x674C...0x6780<br />
* 0x678C...0x67C0<br />
* 0x67CC...0x67FF<br />
<br />
* 0x6B00<br />
* 0x6B06...0x6B40<br />
* 0x6B46...0x6B80<br />
* 0x6B86...0x6BC0<br />
* 0x6BC6...0x6BFF<br />
<br />
* 0x6F00<br />
* 0x6F06...0x6F40<br />
* 0x6F46...0x6F80<br />
* 0x6F86...0x6FC0<br />
* 0x6FC6...0x6FFF<br />
<br />
* 0x7300<br />
* 0x730C...0x7340<br />
* 0x734C...0x7380<br />
* 0x738C...0x73C0<br />
* 0x73CC...0x73FF<br />
<br />
* 0x7700<br />
* 0x770C...0x7740<br />
* 0x774C...0x7780<br />
* 0x778C...0x77C0<br />
* 0x77CC...0x77FF<br />
<br />
* 0x7B00<br />
* 0x7B06...0x7B40<br />
* 0x7B46...0x7B80<br />
* 0x7B86...0x7BC0<br />
* 0x7BC6...0x7BFF<br />
<br />
* 0x7F00<br />
* 0x7F06...0x7F40<br />
* 0x7F46...0x7F80<br />
* 0x7F86...0x7FC0<br />
* 0x7FC6...0x7FDF<br />
* 0x7FE0...0x7FFF: opus_control_header in MPEG-TS [[OpusTS]]<br />
<br />
* 0x8300<br />
* 0x8330...0x8340<br />
* 0x8370...0x8380<br />
* 0x83B0...0x83C0<br />
* 0x83F0...0x83FF<br />
<br />
* 0x8700<br />
* 0x8730...0x8740<br />
* 0x8770...0x8780<br />
* 0x87B0...0x87C0<br />
* 0x87F0...0x87FF<br />
<br />
* 0x8B00<br />
* 0x8B18...0x8B40<br />
* 0x8B58...0x8B80<br />
* 0x8B98...0x8BC0<br />
* 0x8BD8...0x8BFF<br />
<br />
* 0x8F00<br />
* 0x8F18...0x8F40<br />
* 0x8F58...0x8F80<br />
* 0x8F98...0x8FC0<br />
* 0x8FD8...0x8FFF<br />
<br />
* 0x9300<br />
* 0x930C...0x9340<br />
* 0x934C...0x9380<br />
* 0x938C...0x93C0<br />
* 0x93CC...0x93FF<br />
<br />
* 0x9700<br />
* 0x970C...0x9740<br />
* 0x974C...0x9780<br />
* 0x978C...0x97C0<br />
* 0x97CC...0x97FF<br />
<br />
* 0x9B00<br />
* 0x9B06...0x9B40<br />
* 0x9B46...0x9B80<br />
* 0x9B86...0x9BC0<br />
* 0x9BC6...0x9BFF<br />
<br />
* 0x9F00<br />
* 0x9F06...0x9F40<br />
* 0x9F46...0x9F80<br />
* 0x9F86...0x9FC0<br />
* 0x9FC6...0x9FFF<br />
<br />
* 0xA300<br />
* 0xA330...0xA340<br />
* 0xA370...0xA380<br />
* 0xA3B0...0xA3C0<br />
* 0xA3F0...0xA3FF<br />
<br />
* 0xA700<br />
* 0xA730...0xA740<br />
* 0xA770...0xA780<br />
* 0xA7B0...0xA7C0<br />
* 0xA7F0...0xA7FF<br />
<br />
* 0xAB00<br />
* 0xAB18...0xAB40<br />
* 0xAB58...0xAB80<br />
* 0xAB98...0xABC0<br />
* 0xABD8...0xABFF<br />
<br />
* 0xAF00<br />
* 0xAF18...0xAF40<br />
* 0xAF58...0xAF80<br />
* 0xAF98...0xAFC0<br />
* 0xAFD8...0xAFFF<br />
<br />
* 0xB300<br />
* 0xB30C...0xB340<br />
* 0xB34C...0xB380<br />
* 0xB38C...0xB3C0<br />
* 0xB3CC...0xB3FF<br />
<br />
* 0xB700<br />
* 0xB70C...0xB740<br />
* 0xB74C...0xB780<br />
* 0xB78C...0xB7C0<br />
* 0xB7CC...0xB7FF<br />
<br />
* 0xBB00<br />
* 0xBB06...0xBB40<br />
* 0xBB46...0xBB80<br />
* 0xBB86...0xBBC0<br />
* 0xBBC6...0xBBFF<br />
<br />
* 0xBF00<br />
* 0xBF06...0xBF40<br />
* 0xBF46...0xBF80<br />
* 0xBF86...0xBFC0<br />
* 0xBFC6...0xBFFF<br />
<br />
* 0xC300<br />
* 0xC330...0xC340<br />
* 0xC370...0xC380<br />
* 0xC3B0...0xC3C0<br />
* 0xC3F0...0xC3FF<br />
<br />
* 0xC700<br />
* 0xC730...0xC740<br />
* 0xC770...0xC780<br />
* 0xC7B0...0xC7C0<br />
* 0xC7F0...0xC7FF<br />
<br />
* 0xCB00<br />
* 0xCB18...0xCB40<br />
* 0xCB58...0xCB80<br />
* 0xCB98...0xCBC0<br />
* 0xCBD8...0xCBFF<br />
<br />
* 0xCF00<br />
* 0xCF18...0xCF40<br />
* 0xCF58...0xCF80<br />
* 0xCF98...0xCFC0<br />
* 0xCFD8...0xCFFF<br />
<br />
* 0xD300<br />
* 0xD30C...0xD340<br />
* 0xD34C...0xD380<br />
* 0xD38C...0xD3C0<br />
* 0xD3CC...0xD3FF<br />
<br />
* 0xD700<br />
* 0xD70C...0xD740<br />
* 0xD74C...0xD780<br />
* 0xD78C...0xD7C0<br />
* 0xD7CC...0xD7FF<br />
<br />
* 0xDB00<br />
* 0xDB06...0xDB40<br />
* 0xDB46...0xDB80<br />
* 0xDB86...0xDBC0<br />
* 0xDBC6...0xDBFF<br />
<br />
* 0xDF00<br />
* 0xDF06...0xDF40<br />
* 0xDF46...0xDF80<br />
* 0xDF86...0xDFC0<br />
* 0xDFC6...0xDFFF<br />
<br />
* 0xE300<br />
* 0xE330...0xE340<br />
* 0xE370...0xE380<br />
* 0xE3B0...0xE3C0<br />
* 0xE3F0...0xE3FF<br />
<br />
The only restriction that doesn't depend on the number of bytes <br />
in the packet is [R5], which is, "Code 3 packets contain at least <br />
one frame, but no more than 120 ms of audio total."<br />
* 0xE700<br />
* 0xE730...0xE740<br />
* 0xE770...0xE780<br />
* 0xE7B0...0xE7C0<br />
* 0xE7F0...0xE7FF<br />
<br />
* 0xEB00<br />
* 0xEB18...0xEB40<br />
* 0xEB58...0xEB80<br />
* 0xEB98...0xEBC0<br />
* 0xEBD8...0xEBFF<br />
<br />
* 0xEF00<br />
* 0xEF18...0xEF40<br />
* 0xEF58...0xEF80<br />
* 0xEF98...0xEFC0<br />
* 0xEFD8...0xEFFF<br />
<br />
* 0xF300<br />
* 0xF30C...0xF340<br />
* 0xF34C...0xF380<br />
* 0xF38C...0xF3C0<br />
* 0xF3CC...0xF3FF<br />
<br />
* 0xF700<br />
* 0xF70C...0xF740<br />
* 0xF74C...0xF780<br />
* 0xF78C...0xF7C0<br />
* 0xF7CC...0xF7FF<br />
<br />
* 0xFB00<br />
* 0xFB06...0xFB40<br />
* 0xFB46...0xFB80<br />
* 0xFB86...0xFBC0<br />
* 0xFBC6...0xFBFF<br />
<br />
* 0xFF00<br />
* 0xFF06...0xFF40<br />
* 0xFF46...0xFF80<br />
* 0xFF86...0xFFC0<br />
* 0xFFC6...0xFFFF</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusExtensions&diff=16334OpusExtensions2016-04-19T20:50:08Z<p>Rillian: Derf's braindump from IRC</p>
<hr />
<div>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.<br />
<br />
Below is a list of such alternate sequences, to avoid duplication.<br />
<br />
== List of invalid Opus audio data sequences ==<br />
<br />
* `Op` is used as a prefix for metadata headers in .opus files. [https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]<br />
* '0x3FF' in the first 11 bits marks an `opus_access_unit` in mpeg-ts. [[OpusTS]]<br />
<br />
== Constructing invalid sequences ==<br />
<br />
The only restriction that doesn't depend on the number of bytes <br />
in the packet is [R5], which is, "Code 3 packets contain at least <br />
one frame, but no more than 120 ms of audio total."</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusExtensions&diff=16333OpusExtensions2016-04-19T20:47:12Z<p>Rillian: opus_audio_descriptor isn't a PES packet, and starts with a valid TOC, so it doesn't belong on this list.</p>
<hr />
<div>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.<br />
<br />
Below is a list of such alternate sequences, to avoid duplication.<br />
<br />
== List of invalid Opus audio data sequences ==<br />
<br />
* `Op` is used as a prefix for metadata headers in .opus files. [https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]<br />
* '0x3FF' in the first 11 bits marks an `opus_access_unit` in mpeg-ts. [[OpusTS]]</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusExtensions&diff=16332OpusExtensions2016-04-19T20:32:46Z<p>Rillian: </p>
<hr />
<div>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.<br />
<br />
Below is a list of such alternate sequences, to avoid duplication.<br />
<br />
== List of invalid Opus audio data sequences ==<br />
<br />
* `Op` is used as a prefix for metadata headers in .opus files. [https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]<br />
* '0x3FF' in the first 11 bits marks an `opus_access_unit` in mpeg-ts. [[OpusTS]]<br />
* '0x7F` is the tag for the `opus_audio_descriptor` in mpeg-ts. [[OpusTS]]</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusExtensions&diff=16331OpusExtensions2016-04-19T20:20:38Z<p>Rillian: fix references</p>
<hr />
<div>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.<br />
<br />
Below is a list of such alternate sequences, to avoid duplication.<br />
<br />
== List of invalid Opus audio data sequences ==<br />
<br />
* `Og` is used as a prefix for metadata headers in .opus files. [https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]<br />
* '0x3FF' in the first 11 bits marks an `opus_access_unit` in mpeg-ts. [[OpusTS]]<br />
* '0x7F` is the tag for the `opus_audio_descriptor` in mpeg-ts. [[OpusTS]]</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusExtensions&diff=16330OpusExtensions2016-04-19T20:19:51Z<p>Rillian: Update mpeg-ts</p>
<hr />
<div>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.<br />
<br />
Below is a list of such alternate sequences, to avoid duplication.<br />
<br />
== List of invalid Opus audio data sequences ==<br />
<br />
* `Og` is used as a prefix for metadata headers in .opus files. [[https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]]<br />
* '0x3FF' in the first 11 bits marks an `opus_access_unit` in mpeg-ts. [[OpusTS]<br />
* '0x7F` is the tag for the `opus_audio_descriptor` in mpeg-ts. [[OpusTS]]</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusExtensions&diff=16328OpusExtensions2016-04-19T19:51:37Z<p>Rillian: Start a page to track invalid TOC sequences used for extensions.</p>
<hr />
<div>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.<br />
<br />
Below is a list of such alternate sequences, to avoid duplication.<br />
<br />
== List of invalid Opus audio data sequences ==<br />
<br />
* `Og` is used as a prefix for metadata headers in .opus files. [[https://tools.ietf.org/html/draft-ietf-codec-oggopus RFC 7845]]<br />
* '??` an 11-bit sequence (not yet defined) is used to distinguish `opus_control_header` packets in MPEG-TS. [[OpusTS]]</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=16177OpusTodo2016-01-13T18:29:11Z<p>Rillian: Link mp4 draft.</p>
<hr />
<div>== For 1.1.3 ==<br />
* aarch64 and AVX optimizations<br />
<br />
== For 1.2 ==<br />
* Low bitrate quality improvements<br />
* Fix compilation as a single module for gecko<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[https://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation<br />
* RTP payload format. Mono/stereo mapping is complete [[https://tools.ietf.org/html/rfc7587 RFC 7587]], no multichannel mapping yet.<br />
* mp4 mapping. See [[https://opus-codec.org/docs/opus_in_isobmff.html ISO Base Media File Format draft]]<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions:<br />
** write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?) and the proprietary ones)<br />
** write about implementations (libopus encoder/decoder, libavcodec decoder, any others?)<br />
** [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, ...)<br />
** future use in video files (Theora? Dirac? WebM? other future codecs...)<br />
** audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free/public-domain sounds/radio stations in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* Port opusdec to libopusfile/libopusurl.<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** 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<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* EBU R128/Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
<br />
== Third-Party tool enhancements ==<br />
* 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]<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Unconstrained SILK VBR<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size<br />
<br />
[[Category:Opus]]</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=16176OpusTodo2016-01-13T18:27:53Z<p>Rillian: mention unified build bugs</p>
<hr />
<div>== For 1.1.3 ==<br />
* aarch64 and AVX optimizations<br />
<br />
== For 1.2 ==<br />
* Low bitrate quality improvements<br />
* Fix compilation as a single module for gecko<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[https://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation<br />
* RTP payload format. Mono/stereo mapping is complete [[https://tools.ietf.org/html/rfc7587 RFC 7587]], no multichannel mapping yet.<br />
<br />
== Website ==<br />
* De-uglify webpage - some suggestions:<br />
** write about codecs obsoleted by OPUS (Speex, CELT, Vorbis(?) and the proprietary ones)<br />
** write about implementations (libopus encoder/decoder, libavcodec decoder, any others?)<br />
** [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, ...)<br />
** future use in video files (Theora? Dirac? WebM? other future codecs...)<br />
** audio files for storage (like Vorbis, no raw Opus defined, only inside OGG), ... <br />
* Promotional material (some nice free/public-domain sounds/radio stations in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* Port opusdec to libopusfile/libopusurl.<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** 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<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* EBU R128/Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
<br />
== Third-Party tool enhancements ==<br />
* 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]<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Unconstrained SILK VBR<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size<br />
<br />
[[Category:Opus]]</div>Rillianhttps://wiki.xiph.org/index.php?title=MIMETypesCodecs&diff=16156MIMETypesCodecs2015-11-17T23:12:30Z<p>Rillian: /* MIME Types */ Add Opus to the audio/ogg table</p>
<hr />
<div>== Specification of MIME types and respective codecs parameter ==<br />
<br />
Also includes a specification of the recommended file extensions to use with Ogg.<br />
<br />
=== MIME Types ===<br />
<br />
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]:<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
|-<br />
! MIME Type<br />
! Use<br />
! [[Ogg Skeleton|Skeleton]]<br />logical stream?<br />
! File<br />Extension(s)<br />
! Macintosh File<br />Type Code<br />
|-<br />
| video/ogg<br />
| video (possibly with audio)<br /><br />
encapsulated in Ogg<br />
| recommended<br />
| .ogv<br />
| OggV<br />
|-<br />
| audio/ogg<br />
| audio<br />encapsulated in Ogg<br />
| recommended<br />
| .oga<br /><br />
.ogg ([[Vorbis]] I)<br /><br />
.opus ([[Opus]])<br /><br />
.spx ([[Speex]])<br />
| OggA<br />
|-<br />
| application/ogg<br />
| complex/multitrack/multiplexed files<br /><br />
encapsulated in Ogg<br />
| required<br />
| .ogx<br />
| OggX<br />
|}<br />
<br />
[[MIME_Types_and_File_Extensions|Other MIME types]] are still in the registration process.<br />
<br />
=== Codecs Parameter ===<br />
<br />
[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.<br />
<br />
Codecs encapsulated in Ogg require a text identifier at the beginning of the first header page to identify the encapsulated codecs.<br />
<br />
The following table contains the identifiers for existing Xiph codecs and the codec parameter names used for */ogg MIME types (in alphabetical order):<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Codecs Parameter Name<br />
! Codec Type<br />
! Codec Identifier<br />
(decimal, hex, octal)<br />
! Version Field (if available)<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h celt]<br />
| audio<br />
| char[0,8]: <tt>'CELT\ \ \ \ '</tt><br />
hex: <tt>'0x43 0x45 0x4c 0x54 0x20 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0103 0105 0114 0124 0040 0040 0040 0040'</tt><br />
| char[28,4]: version id<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h cmml]<br />
| text<br />
| char[0,8]: <tt>'CMML\0\0\0\0'</tt><br />
hex: <tt>'0x43 0x4d 0x4d 0x4c 0x00 0x00 0x00 0x00'</tt><br />
<br />
oct: <tt>'0103 0115 0115 0114 0000 0000 0000 0000'</tt><br />
| char[8,2]: major version number,<br />
char[10,2]: minor version number<br />
|-<br />
| [[OggDirac|dirac]]<br />
| video<br />
| char[0,5]: <tt>'BBCD\0'</tt><br />
hex: <tt>'0x42 0x42 0x43 0x44 0x00'</tt><br />
<br />
oct: <tt>'0102 0102 0103 0104 0000'</tt><br />
| ??<br />
|-<br />
| [http://flac.sourceforge.net/ogg_mapping.html flac]<br />
| audio<br />
| char[0,5]: <tt>'\177FLAC'</tt><br />
hex: <tt>'0x7F 0x46 0x4C 0x41 0x43'</tt><br />
<br />
oct: <tt>'0177 0106 0114 0101 0103'</tt><br />
| char[5,1]: binary major version number, <br />
char[6,1]: binary minor version number of mapping<br />
|-<br />
| [[OggMNG|jng]]<br />
| video<br />
| char[0,8]: <tt>'\213JNG\r\n\032\n'</tt><br />
hex: <tt>'0x8b 0x4a 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0213 0112 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [[OggKate|kate]]<br />
| text<br />
| char[0,8]: <tt>'\x80kate\0\0\0'</tt><br />
hex: <tt>'0x80 0x6b 0x61 0x74 0x65 0x00 0x00 0x00'</tt><br />
<br />
oct: <tt>'0200 0153 0141 0164 0145 0000 0000 0000'</tt><br />
| char[9,1]: major version number,<br />
char[10,1]: minor version number<br />
|-<br />
| [http://lists.xiph.org/pipermail/vorbis-dev/2001-August/004501.html midi]<br />
| text<br />
| char[0,8]: <tt>'OggMIDI\0'</tt><br />
hex: <tt>'0x4f 0x67 0x67 0x4d 0x49 0x44 0x49 0x00'</tt><br />
<br />
oct: <tt>'0117 0147 0147 0115 0111 0104 0111 0000'</tt><br />
| char[8,1]: version field<br />
|-<br />
| [[OggMNG|mng]]<br />
| video<br />
| char[0,8]: <tt>'\212MNG\r\n\032\n'</tt><br />
hex: <tt>'0x8a 0x4d 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0212 0115 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [[OggOpus|opus]]<br />
| audio<br />
| char[0,8]: <tt>'OpusHead'</tt><br />
hex: <tt>'0x4f 0x70 0x75 0x73 0x48 0x65 0x61 0x64'</tt><br />
<br />
oct: <tt>'0117 0160 0165 0163 0110 0150 0141 0145 1044'</tt><br />
| char[8,1]: version field<br />
|-<br />
| [[OggPCM|pcm]]<br />
| audio<br />
| char[0,8]: <tt>'PCM\ \ \ \ \ '</tt><br />
hex: <tt>'0x50 0x43 0x4d 0x20 0x20 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0120 0103 0115 0040 0040 0040 0040 0040'</tt><br />
| char[8,2]: version major field,<br />
char[10,2]: version minor field<br />
|-<br />
| [[OggMNG|png]]<br />
| video<br />
| char[0,8]: <tt>'\211PNG\r\n\032\n'</tt><br />
hex: <tt>'0x89 0x50 0x4e 0x47 0x0D 0x0A 0x1A 0x0A'</tt><br />
<br />
oct: <tt>'0211 0120 0116 0107 0015 0012 0032 0012'</tt><br />
| ??<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h speex]<br />
| audio<br />
| char[0,8]: <tt>'Speex\ \ \ '</tt><br />
hex: <tt>'0x53 0x70 0x65 0x65 0x78 0x20 0x20 0x20'</tt><br />
<br />
oct: <tt>'0123 0160 0145 0145 0170 0040 0040 0040'</tt><br />
| char[28,4]: version id<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h theora]<br />
| video<br />
| char[0,7]: <tt>'\x80theora'</tt><br />
hex: <tt>'0x80 0x74 0x68 0x65 0x6f 0x72 0x61'</tt><br />
<br />
oct: <tt>'0180 0164 0150 0145 0157 0162 0141'</tt><br />
| char[7,1]: major version number,<br />
char[8,1]: minor version number,<br />
<br />
char[9,1]: version revision number<br />
|-<br />
| [http://svn.annodex.net/liboggz/trunk/src/liboggz/oggz_auto.h vorbis]<br />
| audio<br />
| char[0,7]: <tt>'\x01vorbis'</tt><br />
hex: <tt>'0x01 0x76 0x6f 0x72 0x62 0x69 0x73'</tt><br />
<br />
oct: <tt>'0001 0166 0157 0162 0142 0151 0163'</tt><br />
| char[7,4]: version field<br />
|-<br />
| [[OggYUV4MPEG|yuv4mpeg]]<br />
| video<br />
| char[0,8]: <tt>'YUV4MPEG'</tt><br />
hex: <tt>'0x59 0x55 0x56 0x34 0x4d 0x50 0x45 0x47'</tt><br />
<br />
oct: <tt>'0131 0125 0126 0064 0115 0120 0105 0107'</tt><br />
| char[8,1] = '2' (0x32) for yuv4mpeg format version 2<br />
|}<br />
<br />
The "char[x,y]" fields mean here: start at byte number x (counting from 0) for a length of y bytes.<br />
<br />
[[Category:Ogg]]</div>Rillianhttps://wiki.xiph.org/index.php?title=AdminProcesses&diff=15824AdminProcesses2015-05-09T23:28:52Z<p>Rillian: /* Administration Information */ Update some responsibilities</p>
<hr />
<div>= Administration Information =<br />
<br />
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.<br />
<br />
=== Formats/Projects ===<br />
* [http://en.wikipedia.org/wiki/Annodex Annodex]: Silvia Pfeiffer, Conrad Parker<br />
* [[CMML]]: Silvia Pfeiffer, Conrad Parker<br />
* [[FLAC]]: Erik de Castro Lopo<br />
* [[Icecast]]: Thomas Rücker<br />
* [[Skeleton]]: Conrad Parker<br />
* [[Speex]]: [[User:jmspeex|Jean-Marc Valin]]<br />
* [[Opus]]: [[User:jmspeex|Jean-Marc Valin]]<br />
* [[Theora]]: Ralph Giles<br />
* [[Daala]]: Tim Terriberry, Jack Moffitt<br />
* [[Vorbis]]: Monty<br />
* [[XSPF]]: Lucas Gonze, [[User:Saoshyant|Ivo Emanuel Gonçalves]], [[User:Sping|Sebastian Pipping]]<br />
<br />
=== Other ===<br />
* [[Spread Open Media]]: [[User:Saoshyant|Ivo Emanuel Gonçalves]]<br />
* Xiph Web: ePirat<br />
* Xiph Wiki: ePirate, j^<br />
* Xiph SVN: j^<br />
<br />
== Decision process ==<br />
<br />
Anything that looks like it's officially authorised by Xiph needs approval.<br />
<br />
This may be something that goes on the web or on the wiki or anywhere else.<br />
<br />
If you would like something to as officially authorised, get approval from somebody on the committee (ultimately from Monty if it's unresolvable) beforehand.<br />
<br />
For web pages, you should in particular not edit them in svn or send a patch to the web maintainer unless you have approval.<br />
<br />
== See also ==<br />
* the [[People]] page for an overview of everyone in Xiph</div>Rillianhttps://wiki.xiph.org/index.php?title=AdminProcesses&diff=15823AdminProcesses2015-05-09T23:26:02Z<p>Rillian: /* Formats/Projects */ Add Opus and Daala</p>
<hr />
<div>= Administration Information =<br />
<br />
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.<br />
<br />
=== Formats/Projects ===<br />
* [http://en.wikipedia.org/wiki/Annodex Annodex]: Silvia Pfeiffer, Conrad Parker<br />
* [[CMML]]: Silvia Pfeiffer, Conrad Parker<br />
* [[FLAC]]: Erik de Castro Lopo<br />
* [[Icecast]]: Mike Smith<br />
* [[Skeleton]]: Conrad Parker<br />
* [[Speex]]: [[User:jmspeex|Jean-Marc Valin]]<br />
* [[Opus]]: [[User:jmspeex|Jean-Marc Valin]]<br />
* [[Theora]]: Ralph Giles<br />
* [[Daala]]: Tim Terryberry, Jack Moffitt<br />
* [[Vorbis]]: Monty<br />
* [[XSPF]]: Lucas Gonze, [[User:Saoshyant|Ivo Emanuel Gonçalves]], [[User:Sping|Sebastian Pipping]]<br />
<br />
=== Other ===<br />
* [[Spread Open Media]]: [[User:Saoshyant|Ivo Emanuel Gonçalves]]<br />
* Xiph Web: Atamido<br />
* Xiph Wiki: j^<br />
* Xiph SVN: j^<br />
<br />
== Decision process ==<br />
<br />
Anything that looks like it's officially authorised by Xiph needs approval.<br />
<br />
This may be something that goes on the web or on the wiki or anywhere else.<br />
<br />
If you would like something to as officially authorised, get approval from somebody on the committee (ultimately from Monty if it's unresolvable) beforehand.<br />
<br />
For web pages, you should in particular not edit them in svn or send a patch to the web maintainer unless you have approval.<br />
<br />
== See also ==<br />
* the [[People]] page for an overview of everyone in Xiph</div>Rillianhttps://wiki.xiph.org/index.php?title=XiphWiki:Features&diff=15791XiphWiki:Features2015-04-30T14:59:25Z<p>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.</p>
<hr />
<div>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).<br /><br />
This was a huge update, as 1.16 was released in the end of 2010 (it was nearly 5 years old!).<br />
<br />
== New Features ==<br />
With the update to the new MediaWiki version, there are some new features which are explained in detail in this section.<br />
<br />
=== Skin ===<br />
One of the most noticeable new ‘features’ is probably the new design.<br />
<br />
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]].<br />
<br />
=== HiDPI Images ===<br />
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]!<br />
<br />
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.<br />
<br />
=== Syntax Highlighting ===<br />
Yes, finally the Wiki is able to do syntax highlighting.<br />
<br />
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:<br />
<br />
<pre><nowiki><syntaxhighlight lang="php"><br />
<?php $coolcode = false; ?><br />
</syntaxhighlight></nowiki></pre><br />
<br />
which would produce following output:<br />
<br />
<syntaxhighlight lang="php"><br />
<?php $coolcode = false; ?><br />
</syntaxhighlight><br />
<br />
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].<br />
<br />
=== Mobile View ===<br />
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.<br />
<br />
=== License Notes ===<br />
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.<br />
<br />
== Changed behavior ==<br />
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.<br />
<br />
=== Visitor count ===<br />
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.<br />
<br />
=== News Channel removed ===<br />
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.<br />
<br />
=== Ogg Media Player removed ===<br />
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.)<br />
<br />
== Administration Information ==<br />
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.<br />
<br />
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!<br />
Write a short comment about what the option you add does and, if it is not clear, why this is needed.<br />
<br />
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!<br />
<br />
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).<br />
<br />
Thanks for reading! Happy Wiki-editing.</div>Rillianhttps://wiki.xiph.org/index.php?title=Summer_of_Code_Mentoring&diff=15493Summer of Code Mentoring2015-02-20T06:42:41Z<p>Rillian: /* Questionaire for 2015 */ Move answer to the correct question.</p>
<hr />
<div>== Xiph.Org Application as a mentoring organization ==<br />
<br />
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.<br />
<br />
==== Describe your organization. ====<br />
<br />
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. <br />
<br />
==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====<br />
<br />
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.<br />
<br />
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&mdash;of course&mdash;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.<br />
<br />
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.<br />
<br />
==== Has your organization participated in past Google Summer of Codes? ====<br />
<br />
Yes<br />
<br />
==== 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. ====<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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 &mdash; the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====<br />
<br />
We have participated previously, in 2006, 2007, 2008 and 2009.<br />
We applied in 2010, but weren't chosen.<br />
<br />
==== What Open Source Initiative approved license(s) does your project use? ====<br />
<br />
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.<br />
<br />
Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.<br />
<br />
==== What is the URL for your Ideas list? ====<br />
<br />
http://wiki.xiph.org/Summer_of_Code_2015<br />
<br />
==== What is the main development mailing list for your organization? ====<br />
<br />
Icecast will be the main Xiph.org project for GSoC this year.<br />
<br />
[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]<br />
<br />
[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]<br />
<br />
A complete listing of our lists is available at:<br />
<br />
http://lists.xiph.org/mailman/listinfo/<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
<br />
The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]<br />
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]<br />
<br />
==== Who will be your backup organization administrator? ====<br />
<br />
'''tbd'''<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====<br />
<br />
http://wiki.xiph.org/index.php/Summer_of_Code_Applications<br />
<br />
==== What criteria did you use to select the mentors? Please be as specific as possible. ====<br />
<br />
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).<br />
<br />
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).<br />
<br />
'''''TODO: Introduce mentors briefly.'''''<br />
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
==== 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. ====<br />
<br />
==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
We will encourage them not to consider this just "a summer job", but as being part of a real community &mdash; and doing something that is both interesting, and useful to the wider world.<br />
<br />
==== Additional items not listed by the GSoC FAQ ====<br />
===== Who will be your main organization administrator =====<br />
<br />
Thomas B. Rücker, maintainer of the Icecast project.<br />
<br />
===== Who will your mentors be? =====<br />
<br />
* '''Thomas B. Rücker''' - IRC nick: ''tbr''<br />
* '''NN''' - IRC nick:<br />
<br />
<br />
== Questionaire for 2015 ==<br />
<br />
<br />
=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
=== 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. ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===<br />
<br />
Three mentors have volunteered.<br />
<br />
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).<br />
<br />
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).<br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What steps will you take to encourage students to interact with your project's community before and during the program? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
=== 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. ===<br />
<br />
=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===</div>Rillianhttps://wiki.xiph.org/index.php?title=Summer_of_Code_Mentoring&diff=15492Summer of Code Mentoring2015-02-20T06:32:01Z<p>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.</p>
<hr />
<div>== Xiph.Org Application as a mentoring organization ==<br />
<br />
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.<br />
<br />
==== Describe your organization. ====<br />
<br />
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. <br />
<br />
==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====<br />
<br />
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.<br />
<br />
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&mdash;of course&mdash;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.<br />
<br />
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.<br />
<br />
==== Has your organization participated in past Google Summer of Codes? ====<br />
<br />
Yes<br />
<br />
==== 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. ====<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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 &mdash; the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====<br />
<br />
We have participated previously, in 2006, 2007, 2008 and 2009.<br />
We applied in 2010, but weren't chosen.<br />
<br />
==== What Open Source Initiative approved license(s) does your project use? ====<br />
<br />
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.<br />
<br />
Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.<br />
<br />
==== What is the URL for your Ideas list? ====<br />
<br />
http://wiki.xiph.org/Summer_of_Code_2015<br />
<br />
==== What is the main development mailing list for your organization? ====<br />
<br />
Icecast will be the main Xiph.org project for GSoC this year.<br />
<br />
[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]<br />
<br />
[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]<br />
<br />
A complete listing of our lists is available at:<br />
<br />
http://lists.xiph.org/mailman/listinfo/<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
<br />
The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]<br />
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]<br />
<br />
==== Who will be your backup organization administrator? ====<br />
<br />
'''tbd'''<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====<br />
<br />
http://wiki.xiph.org/index.php/Summer_of_Code_Applications<br />
<br />
==== What criteria did you use to select the mentors? Please be as specific as possible. ====<br />
<br />
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).<br />
<br />
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).<br />
<br />
'''''TODO: Introduce mentors briefly.'''''<br />
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
==== 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. ====<br />
<br />
==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
We will encourage them not to consider this just "a summer job", but as being part of a real community &mdash; and doing something that is both interesting, and useful to the wider world.<br />
<br />
==== Additional items not listed by the GSoC FAQ ====<br />
===== Who will be your main organization administrator =====<br />
<br />
Thomas B. Rücker, maintainer of the Icecast project.<br />
<br />
===== Who will your mentors be? =====<br />
<br />
* '''Thomas B. Rücker''' - IRC nick: ''tbr''<br />
* '''NN''' - IRC nick:<br />
<br />
<br />
== Questionaire for 2015 ==<br />
<br />
<br />
=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
=== 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. ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===<br />
<br />
Three mentors have volunteered.<br />
<br />
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).<br />
<br />
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).<br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What steps will you take to encourage students to interact with your project's community before and during the program? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===<br />
<br />
=== 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. ===<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===</div>Rillianhttps://wiki.xiph.org/index.php?title=Summer_of_Code_Mentoring&diff=15491Summer of Code Mentoring2015-02-20T06:27:37Z<p>Rillian: /* Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? */</p>
<hr />
<div>== Xiph.Org Application as a mentoring organization ==<br />
<br />
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.<br />
<br />
==== Describe your organization. ====<br />
<br />
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. <br />
<br />
==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====<br />
<br />
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.<br />
<br />
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&mdash;of course&mdash;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.<br />
<br />
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.<br />
<br />
==== Has your organization participated in past Google Summer of Codes? ====<br />
<br />
Yes<br />
<br />
==== 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. ====<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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 &mdash; the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====<br />
<br />
We have participated previously, in 2006, 2007, 2008 and 2009.<br />
We applied in 2010, but weren't chosen.<br />
<br />
==== What Open Source Initiative approved license(s) does your project use? ====<br />
<br />
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.<br />
<br />
Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.<br />
<br />
==== What is the URL for your Ideas list? ====<br />
<br />
http://wiki.xiph.org/Summer_of_Code_2015<br />
<br />
==== What is the main development mailing list for your organization? ====<br />
<br />
Icecast will be the main Xiph.org project for GSoC this year.<br />
<br />
[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]<br />
<br />
[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]<br />
<br />
A complete listing of our lists is available at:<br />
<br />
http://lists.xiph.org/mailman/listinfo/<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
<br />
The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]<br />
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]<br />
<br />
==== Who will be your backup organization administrator? ====<br />
<br />
'''tbd'''<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====<br />
<br />
http://wiki.xiph.org/index.php/Summer_of_Code_Applications<br />
<br />
==== What criteria did you use to select the mentors? Please be as specific as possible. ====<br />
<br />
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).<br />
<br />
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).<br />
<br />
'''''TODO: Introduce mentors briefly.'''''<br />
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
==== 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. ====<br />
<br />
==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
We will encourage them not to consider this just "a summer job", but as being part of a real community &mdash; and doing something that is both interesting, and useful to the wider world.<br />
<br />
==== Additional items not listed by the GSoC FAQ ====<br />
===== Who will be your main organization administrator =====<br />
<br />
Thomas B. Rücker, maintainer of the Icecast project.<br />
<br />
===== Who will your mentors be? =====<br />
<br />
* '''Thomas B. Rücker''' - IRC nick: ''tbr''<br />
* '''NN''' - IRC nick:<br />
<br />
<br />
== Questionaire for 2015 ==<br />
<br />
<br />
=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
=== 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. ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===<br />
<br />
Two mentors have volunteered.<br />
<br />
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).<br />
<br />
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). <br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What steps will you take to encourage students to interact with your project's community before and during the program? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===<br />
<br />
=== 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. ===<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===</div>Rillianhttps://wiki.xiph.org/index.php?title=Summer_of_Code_Mentoring&diff=15490Summer of Code Mentoring2015-02-20T06:27:06Z<p>Rillian: /* Questionaire for 2015 */ Move codec sentence to goals section</p>
<hr />
<div>== Xiph.Org Application as a mentoring organization ==<br />
<br />
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.<br />
<br />
==== Describe your organization. ====<br />
<br />
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. <br />
<br />
==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====<br />
<br />
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.<br />
<br />
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&mdash;of course&mdash;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.<br />
<br />
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.<br />
<br />
==== Has your organization participated in past Google Summer of Codes? ====<br />
<br />
Yes<br />
<br />
==== 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. ====<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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 &mdash; the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====<br />
<br />
We have participated previously, in 2006, 2007, 2008 and 2009.<br />
We applied in 2010, but weren't chosen.<br />
<br />
==== What Open Source Initiative approved license(s) does your project use? ====<br />
<br />
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.<br />
<br />
Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.<br />
<br />
==== What is the URL for your Ideas list? ====<br />
<br />
http://wiki.xiph.org/Summer_of_Code_2015<br />
<br />
==== What is the main development mailing list for your organization? ====<br />
<br />
Icecast will be the main Xiph.org project for GSoC this year.<br />
<br />
[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]<br />
<br />
[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]<br />
<br />
A complete listing of our lists is available at:<br />
<br />
http://lists.xiph.org/mailman/listinfo/<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
<br />
The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]<br />
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]<br />
<br />
==== Who will be your backup organization administrator? ====<br />
<br />
'''tbd'''<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====<br />
<br />
http://wiki.xiph.org/index.php/Summer_of_Code_Applications<br />
<br />
==== What criteria did you use to select the mentors? Please be as specific as possible. ====<br />
<br />
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).<br />
<br />
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).<br />
<br />
'''''TODO: Introduce mentors briefly.'''''<br />
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
==== 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. ====<br />
<br />
==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
We will encourage them not to consider this just "a summer job", but as being part of a real community &mdash; and doing something that is both interesting, and useful to the wider world.<br />
<br />
==== Additional items not listed by the GSoC FAQ ====<br />
===== Who will be your main organization administrator =====<br />
<br />
Thomas B. Rücker, maintainer of the Icecast project.<br />
<br />
===== Who will your mentors be? =====<br />
<br />
* '''Thomas B. Rücker''' - IRC nick: ''tbr''<br />
* '''NN''' - IRC nick:<br />
<br />
<br />
== Questionaire for 2015 ==<br />
<br />
<br />
=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
=== 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. ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This focus will avoiding the previous emphasis on codecs, which proved very challenging to most student participants.<br />
<br />
<br />
=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===<br />
<br />
Two mentors have volunteered.<br />
<br />
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).<br />
<br />
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). <br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What steps will you take to encourage students to interact with your project's community before and during the program? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===<br />
<br />
=== 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. ===<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===</div>Rillianhttps://wiki.xiph.org/index.php?title=Summer_of_Code_Mentoring&diff=15489Summer of Code Mentoring2015-02-20T06:22:54Z<p>Rillian: copy remaining answers from above</p>
<hr />
<div>== Xiph.Org Application as a mentoring organization ==<br />
<br />
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.<br />
<br />
==== Describe your organization. ====<br />
<br />
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. <br />
<br />
==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====<br />
<br />
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.<br />
<br />
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&mdash;of course&mdash;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.<br />
<br />
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.<br />
<br />
==== Has your organization participated in past Google Summer of Codes? ====<br />
<br />
Yes<br />
<br />
==== 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. ====<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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 &mdash; the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====<br />
<br />
We have participated previously, in 2006, 2007, 2008 and 2009.<br />
We applied in 2010, but weren't chosen.<br />
<br />
==== What Open Source Initiative approved license(s) does your project use? ====<br />
<br />
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.<br />
<br />
Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.<br />
<br />
==== What is the URL for your Ideas list? ====<br />
<br />
http://wiki.xiph.org/Summer_of_Code_2015<br />
<br />
==== What is the main development mailing list for your organization? ====<br />
<br />
Icecast will be the main Xiph.org project for GSoC this year.<br />
<br />
[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]<br />
<br />
[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]<br />
<br />
A complete listing of our lists is available at:<br />
<br />
http://lists.xiph.org/mailman/listinfo/<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
<br />
The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]<br />
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]<br />
<br />
==== Who will be your backup organization administrator? ====<br />
<br />
'''tbd'''<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====<br />
<br />
http://wiki.xiph.org/index.php/Summer_of_Code_Applications<br />
<br />
==== What criteria did you use to select the mentors? Please be as specific as possible. ====<br />
<br />
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).<br />
<br />
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).<br />
<br />
'''''TODO: Introduce mentors briefly.'''''<br />
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
==== 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. ====<br />
<br />
==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
We will encourage them not to consider this just "a summer job", but as being part of a real community &mdash; and doing something that is both interesting, and useful to the wider world.<br />
<br />
==== Additional items not listed by the GSoC FAQ ====<br />
===== Who will be your main organization administrator =====<br />
<br />
Thomas B. Rücker, maintainer of the Icecast project.<br />
<br />
===== Who will your mentors be? =====<br />
<br />
* '''Thomas B. Rücker''' - IRC nick: ''tbr''<br />
* '''NN''' - IRC nick:<br />
<br />
<br />
== Questionaire for 2015 ==<br />
<br />
<br />
=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
=== 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. ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===<br />
<br />
Two mentors have volunteered.<br />
<br />
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).<br />
<br />
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). <br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What steps will you take to encourage students to interact with your project's community before and during the program? ===<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===<br />
<br />
=== 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. ===<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===</div>Rillianhttps://wiki.xiph.org/index.php?title=Summer_of_Code_Mentoring&diff=15488Summer of Code Mentoring2015-02-20T06:19:28Z<p>Rillian: Answers so far, copied from above with some minor modifications.</p>
<hr />
<div>== Xiph.Org Application as a mentoring organization ==<br />
<br />
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.<br />
<br />
==== Describe your organization. ====<br />
<br />
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. <br />
<br />
==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====<br />
<br />
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.<br />
<br />
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&mdash;of course&mdash;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.<br />
<br />
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.<br />
<br />
==== Has your organization participated in past Google Summer of Codes? ====<br />
<br />
Yes<br />
<br />
==== 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. ====<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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 &mdash; the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====<br />
<br />
We have participated previously, in 2006, 2007, 2008 and 2009.<br />
We applied in 2010, but weren't chosen.<br />
<br />
==== What Open Source Initiative approved license(s) does your project use? ====<br />
<br />
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.<br />
<br />
Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.<br />
<br />
==== What is the URL for your Ideas list? ====<br />
<br />
http://wiki.xiph.org/Summer_of_Code_2015<br />
<br />
==== What is the main development mailing list for your organization? ====<br />
<br />
Icecast will be the main Xiph.org project for GSoC this year.<br />
<br />
[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]<br />
<br />
[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]<br />
<br />
A complete listing of our lists is available at:<br />
<br />
http://lists.xiph.org/mailman/listinfo/<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
<br />
The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]<br />
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]<br />
<br />
==== Who will be your backup organization administrator? ====<br />
<br />
'''tbd'''<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====<br />
<br />
http://wiki.xiph.org/index.php/Summer_of_Code_Applications<br />
<br />
==== What criteria did you use to select the mentors? Please be as specific as possible. ====<br />
<br />
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).<br />
<br />
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).<br />
<br />
'''''TODO: Introduce mentors briefly.'''''<br />
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
==== 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. ====<br />
<br />
==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
We will encourage them not to consider this just "a summer job", but as being part of a real community &mdash; and doing something that is both interesting, and useful to the wider world.<br />
<br />
==== Additional items not listed by the GSoC FAQ ====<br />
===== Who will be your main organization administrator =====<br />
<br />
Thomas B. Rücker, maintainer of the Icecast project.<br />
<br />
===== Who will your mentors be? =====<br />
<br />
* '''Thomas B. Rücker''' - IRC nick: ''tbr''<br />
* '''NN''' - IRC nick:<br />
<br />
<br />
== Questionaire for 2015 ==<br />
<br />
<br />
=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
=== 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. ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===<br />
<br />
Two mentors have volunteered.<br />
<br />
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).<br />
<br />
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). <br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
=== What steps will you take to encourage students to interact with your project's community before and during the program? ===<br />
<br />
=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===<br />
<br />
=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===<br />
<br />
=== 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. ===<br />
<br />
=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===</div>Rillianhttps://wiki.xiph.org/index.php?title=Summer_of_Code_Mentoring&diff=15487Summer of Code Mentoring2015-02-20T06:17:49Z<p>Rillian: Dump questionaire from the 2015 organization application</p>
<hr />
<div>== Xiph.Org Application as a mentoring organization ==<br />
<br />
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.<br />
<br />
==== Describe your organization. ====<br />
<br />
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. <br />
<br />
==== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ====<br />
<br />
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.<br />
<br />
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&mdash;of course&mdash;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.<br />
<br />
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.<br />
<br />
==== Has your organization participated in past Google Summer of Codes? ====<br />
<br />
Yes<br />
<br />
==== 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. ====<br />
<br />
The Xiph.Org Foundation was invited to participate in GSoc in 2006, 2007, 2008 and 2009, and mentored Annodex-related projects as well.<br />
<br />
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. <br />
<br />
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.<br />
<br />
The remaining three were unsuccessful through lack of necessary skills, health complications, insufficient motivation, or some combination of all of these.<br />
<br />
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 &mdash; the students reached the minimum goals set, but little more, and did not maintain contact with Xiph after the program. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==== If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)? ====<br />
<br />
We have participated previously, in 2006, 2007, 2008 and 2009.<br />
We applied in 2010, but weren't chosen.<br />
<br />
==== What Open Source Initiative approved license(s) does your project use? ====<br />
<br />
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.<br />
<br />
Our applications are generally GPL, LGPL or (GPL-compatible) modified. BSD is also acceptable.<br />
<br />
==== What is the URL for your Ideas list? ====<br />
<br />
http://wiki.xiph.org/Summer_of_Code_2015<br />
<br />
==== What is the main development mailing list for your organization? ====<br />
<br />
Icecast will be the main Xiph.org project for GSoC this year.<br />
<br />
[http://lists.xiph.org/mailman/admindb/icecast-dev Icecast developer mailing list]<br />
<br />
[http://dir.gmane.org/gmane.comp.audio.icecast.devel Gmane archive of the Icecast developer mailing list]<br />
<br />
A complete listing of our lists is available at:<br />
<br />
http://lists.xiph.org/mailman/listinfo/<br />
<br />
==== What is the main IRC channel for your organization? ====<br />
<br />
The main channel for Xiph.org is [http://webchat.freenode.net?nick=gsoc.&channels=%23xiph&prompt=1&uio=d4 #xiph on Freenode]<br />
The main Icecast channel is [http://webchat.freenode.net?nick=gsoc.&channels=%23icecast&prompt=1&uio=d4 #icecast on Freenode]<br />
<br />
==== Who will be your backup organization administrator? ====<br />
<br />
'''tbd'''<br />
<br />
==== Does your organization have an application template you would like to see students use? If so, please provide it now. ====<br />
<br />
http://wiki.xiph.org/index.php/Summer_of_Code_Applications<br />
<br />
==== What criteria did you use to select the mentors? Please be as specific as possible. ====<br />
<br />
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).<br />
<br />
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).<br />
<br />
'''''TODO: Introduce mentors briefly.'''''<br />
==== What is your plan for dealing with disappearing students? Please be as specific as possible. ====<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== What is your plan for dealing with disappearing mentors? Please be as specific as possible. ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====<br />
<br />
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. <br />
<br />
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.<br />
<br />
==== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ====<br />
<br />
We are a well established organization and participated in GSoC in the past.<br />
<br />
==== 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. ====<br />
<br />
==== What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes? ====<br />
<br />
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.<br />
<br />
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.<br />
<br />
We will encourage them not to consider this just "a summer job", but as being part of a real community &mdash; and doing something that is both interesting, and useful to the wider world.<br />
<br />
==== Additional items not listed by the GSoC FAQ ====<br />
===== Who will be your main organization administrator =====<br />
<br />
Thomas B. Rücker, maintainer of the Icecast project.<br />
<br />
===== Who will your mentors be? =====<br />
<br />
* '''Thomas B. Rücker''' - IRC nick: ''tbr''<br />
* '''NN''' - IRC nick:<br />
<br />
<br />
== Questionaire for 2015 ==<br />
<br />
<br />
=== If you did not choose "veteran" in the checkbox, have you applied in the past? If so, for what year(s)? ===<br />
<br />
=== 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. ===<br />
<br />
=== Why is your organization applying to participate in Google Summer of Code 2015? What do you hope to gain by participating? ===<br />
<br />
=== How many potential mentors do you have for this year's program? What criteria did you use to select them? ===<br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
=== What steps will you take to encourage students to interact with your project's community before and during the program? ===<br />
<br />
=== What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes? ===<br />
<br />
=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. ===<br />
<br />
=== 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. ===<br />
<br />
=== Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? ===</div>Rillianhttps://wiki.xiph.org/index.php?title=How_to_help&diff=15460How to help2015-02-11T21:58:11Z<p>Rillian: Move OggDSF downpage. This is no longer an active project</p>
<hr />
<div>__NOTOC__<br />
This page is intended to collect ideas and areas where new participants can contribute to Xiph.org initiatives. <br />
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.<br />
<br />
One of the best ways people can contribute is by using the tools and formats. This accomplishes two primary goals:<br />
#By providing materials in free formats you help lower the barriers to adoption for others<br />
#By using the tools you will discover problems which you can report contributing to further development and refinement <br />
<br />
Must of our organizational discussion happens over irc on the freenode.net network. See project-specific channels below,<br />
or join #xiph on irc.freenode.net for general information.<br />
<br />
<br />
==Software outreach==<br />
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. <br />
<br />
Relevant contribution areas:<br />
#Testing, e.g. [[TheoraTestsuite]] and reporting bugs into the relevant bug trackers<br />
#Cross porting features<br />
#Updating tools to support the latest features in the Xiph.org implementations (e.g. two-pass encoding for video tools)<br />
<br />
==Theora specific activities==<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
*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)<br />
<br />
*Decoder assembly optimization for additional platforms (MIPS64; PPC)<br />
**Skills required: optimization and development experience on the relevant platform. <br />
<br />
*Decoder general performance improvements<br />
**Skills required: C language; Use of a profiler. Optionally: SIMD assembly on relevant platforms.<br />
<br />
==Vorbis specific activities==<br />
Places to discuss development: Vorbis mailing list; #vorbis on irc.freenode.net<br />
<br />
<br />
*Identifying test samples where Vorbis encodings at very high quality are not completely transparent under careful listening tests. <br />
*Identifying test cases that exemplify the improvements in the current AoTuV development. (Helps with AoTuV merging)<br />
*Identifying test samples where Vorbis performs worse than other formats.<br />
<br />
==Skeleton specific activities==<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
==Liboggz specific activities==<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
==Cortado specific activities==<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
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.<br />
* See the cortado todo: [[Cortado/todo]]<br />
<br />
==Flash port of Theora==<br />
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.<br />
<br />
==Additional tools work==<br />
*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.<br />
<br />
==OggDSF specific activities==<br />
Directshow is the windows video codec API, OggDSF provides support for Vorbis/Theora/Speex/Flac and Ogg in directshow.<br />
<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
*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. <br />
<br />
<br />
==PR and organizational matters==<br />
*Participate in external promotional activities such as [http://www.fsf.org/resources/formats/playogg PlayOgg!]<br />
*[http://videoonwikipedia.org Contribute] to Wikipedia's video collection<br />
*Locate media coverage regarding free formats and related areas and share it with the the mailing lists<br />
*Encourage additional media distributors to support HTML5 with Theora<br />
<br />
==Internet outreach==<br />
* Encourage places using poor tools (e.g. ffvorbis encoder) to switch to better software.<br />
* Encourage adoption of Theora video for html5 and theora based fallbacks</div>Rillianhttps://wiki.xiph.org/index.php?title=How_to_help&diff=15459How to help2015-02-11T21:57:30Z<p>Rillian: Mention #xiph at the top of the page.</p>
<hr />
<div>__NOTOC__<br />
This page is intended to collect ideas and areas where new participants can contribute to Xiph.org initiatives. <br />
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.<br />
<br />
One of the best ways people can contribute is by using the tools and formats. This accomplishes two primary goals:<br />
#By providing materials in free formats you help lower the barriers to adoption for others<br />
#By using the tools you will discover problems which you can report contributing to further development and refinement <br />
<br />
Must of our organizational discussion happens over irc on the freenode.net network. See project-specific channels below,<br />
or join #xiph on irc.freenode.net for general information.<br />
<br />
<br />
==OggDSF specific activities==<br />
Directshow is the windows video codec API, OggDSF provides support for Vorbis/Theora/Speex/Flac and Ogg in directshow.<br />
<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
*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. <br />
<br />
==Software outreach==<br />
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. <br />
<br />
Relevant contribution areas:<br />
#Testing, e.g. [[TheoraTestsuite]] and reporting bugs into the relevant bug trackers<br />
#Cross porting features<br />
#Updating tools to support the latest features in the Xiph.org implementations (e.g. two-pass encoding for video tools)<br />
<br />
==Theora specific activities==<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
*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)<br />
<br />
*Decoder assembly optimization for additional platforms (MIPS64; PPC)<br />
**Skills required: optimization and development experience on the relevant platform. <br />
<br />
*Decoder general performance improvements<br />
**Skills required: C language; Use of a profiler. Optionally: SIMD assembly on relevant platforms.<br />
<br />
==Vorbis specific activities==<br />
Places to discuss development: Vorbis mailing list; #vorbis on irc.freenode.net<br />
<br />
<br />
*Identifying test samples where Vorbis encodings at very high quality are not completely transparent under careful listening tests. <br />
*Identifying test cases that exemplify the improvements in the current AoTuV development. (Helps with AoTuV merging)<br />
*Identifying test samples where Vorbis performs worse than other formats.<br />
<br />
==Skeleton specific activities==<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
==Liboggz specific activities==<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
==Cortado specific activities==<br />
Places to discuss development: Theora mailing list; #theora on irc.freenode.net<br />
<br />
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.<br />
* See the cortado todo: [[Cortado/todo]]<br />
<br />
==Flash port of Theora==<br />
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.<br />
<br />
==Additional tools work==<br />
*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.<br />
<br />
==PR and organizational matters==<br />
*Participate in external promotional activities such as [http://www.fsf.org/resources/formats/playogg PlayOgg!]<br />
*[http://videoonwikipedia.org Contribute] to Wikipedia's video collection<br />
*Locate media coverage regarding free formats and related areas and share it with the the mailing lists<br />
*Encourage additional media distributors to support HTML5 with Theora<br />
<br />
==Internet outreach==<br />
* Encourage places using poor tools (e.g. ffvorbis encoder) to switch to better software.<br />
* Encourage adoption of Theora video for html5 and theora based fallbacks</div>Rillianhttps://wiki.xiph.org/index.php?title=MIME_Types_and_File_Extensions&diff=15268MIME Types and File Extensions2015-01-08T22:32:43Z<p>Rillian: Add opus filetype.</p>
<hr />
<div>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.<br />
<br />
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.<br />
<br />
IMPLEMENTATION recommendations and patches: see [[MIME-Migration]].<br />
<br />
== .ogg - audio/ogg ==<br />
<br />
* Ogg Vorbis I Profile<br />
* .ogg applies now for Vorbis I files only<br />
* .ogg has more recently also been used for Ogg FLAC and for Theora, too &mdash; these uses are deprecated now in favor of .oga and .ogv respectively<br />
* has been defined in RFC 3534 http://www.ietf.org/rfc/rfc3534.txt for application/ogg, so rfc 3534 will be re-defined<br />
<br />
RATIONALE: .ogg has traditionally been used for Vorbis I files, in particular in HW players, hence it is kept for backwards-compatibility<br />
<br />
== .ogv - video/ogg ==<br />
<br />
* Ogg Video Profile (a/v in Ogg container)<br />
* apps supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams<br />
* covers e.g. [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg<br />
* This list is not exhaustive (for example, [[Dirac]] + FLAC is acceptable too)<br />
* SHOULD contain a Skeleton track and/or MAY contain a CMML logical bitstream.<br />
<br />
== .opus - audio/ogg ==<br />
<br />
* Ogg Opus profile<br />
* Defined by https://tools.ietf.org/html/draft-ietf-codec-oggopus<br />
<br />
== .oga - audio/ogg ==<br />
<br />
* Ogg Audio Profile (audio in Ogg container)<br />
* Applications supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams<br />
* Covers Ogg [[FLAC]], [[Opus]], [[Ghost]], and [[OggPCM]] <br />
* Although they share the same MIME type, Vorbis and Speex use different file extensions.<br />
* SHOULD contain a Skeleton logical bitstream.<br />
* Vorbis and Speex may use .oga, but it is not the prefered method of distributing these files because of backwards-compatibility issues.<br />
<br />
== .ogx - application/ogg ==<br />
<br />
* Ogg Multiplex Profile (anything in [[Ogg]])<br />
* can contain any logical bitstreams multiplexed together in an ogg container<br />
* will replace the .ogg extension from RFC 3534 http://www.ietf.org/rfc/rfc3534.txt<br />
* random multitrack files MUST contain a [[Skeleton]] track to identify all containing logical bitstreams<br />
* apps that identify a logical bitstream which they cannot decode SHOULD ignore it but MAY still decode the ones they can<br />
* thus, e.g. an annodex file can gracefully degrade to .ogx if an app cannot decode [[CMML]] and/or [[Skeleton]]<br />
* USE: application/ogg has been registered, so can be used immediately<br />
<br />
== .spx - audio/ogg ==<br />
<br />
* Ogg Speex Profile<br />
* .spx has traditionally been used for Speex files within Ogg and should be considered for backwards-compatibility<br />
<br />
== .flac - audio/flac ==<br />
<br />
* FLAC in native encapsulation format<br />
<br />
== .anx - application/annodex ==<br />
<br />
* Profile for multiplexed Ogg that includes a skeleton track and at least one CMML logical bitstream<br />
* apps that identify a logical bitstream which they cannot decode SHOULD ignore it but MAY still decode the ones they can<br />
* 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<br />
<br />
== .axa - audio/annodex ==<br />
<br />
* Profile for audio in Annodex <br />
* covers e.g. [[Vorbis]], [[Speex]], [[FLAC]], [[Opus]], [[Ghost]], [[OggPCM]] inside Ogg with Skeleton and CMML<br />
<br />
== .axv - video/annodex ==<br />
<br />
* Profile for video in Annodex <br />
* covers e.g. [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg with Skeleton and CMML<br />
<br />
== .xspf - application/xspf+xml ==<br />
<br />
* Profile for XSPF<br />
* Covers [[XSPF]], while being used through XML<br />
* Does not cover [[JSPF]], which is XSPF but on JSON<br />
<br />
== Ogg Kate files - application/kate ==<br />
<br />
* Binary representation of Kate encapsulated in Ogg<br />
* may have a skeleton<br />
* can be used to identify the mime type of the track itself (e.g. in skeleton)<br />
* uses .ogx extension when in a file by itself<br />
* is subdued by the dominant mime type if in a audio or video file to become audio/ogg or video/ogg<br />
<br />
== Codec MIME types ==<br />
<br />
Codecs need their own MIME types for streaming in RTP and to be used in multitrack ogg files using skeleton:<br />
<br />
* audio/vorbis for Vorbis without container<br />
* video/theora for Theora without container<br />
* audio/speex for Speex without container<br />
* audio/flac for FLAC without and in native container<br />
* audio/opus for Opus without container<br />
* text/cmml for CMML without container<br />
* application/kate for the textual representation of Kate (.kate files)</div>Rillianhttps://wiki.xiph.org/index.php?title=MIME_Types_and_File_Extensions&diff=15267MIME Types and File Extensions2015-01-08T22:31:11Z<p>Rillian: Put more relevant extensions at the top</p>
<hr />
<div>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.<br />
<br />
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.<br />
<br />
IMPLEMENTATION recommendations and patches: see [[MIME-Migration]].<br />
<br />
== .ogg - audio/ogg ==<br />
<br />
* Ogg Vorbis I Profile<br />
* .ogg applies now for Vorbis I files only<br />
* .ogg has more recently also been used for Ogg FLAC and for Theora, too &mdash; these uses are deprecated now in favor of .oga and .ogv respectively<br />
* has been defined in RFC 3534 http://www.ietf.org/rfc/rfc3534.txt for application/ogg, so rfc 3534 will be re-defined<br />
<br />
RATIONALE: .ogg has traditionally been used for Vorbis I files, in particular in HW players, hence it is kept for backwards-compatibility<br />
<br />
== .ogv - video/ogg ==<br />
<br />
* Ogg Video Profile (a/v in Ogg container)<br />
* apps supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams<br />
* covers e.g. [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg<br />
* This list is not exhaustive (for example, [[Dirac]] + FLAC is acceptable too)<br />
* SHOULD contain a Skeleton track and/or MAY contain a CMML logical bitstream.<br />
<br />
== .oga - audio/ogg ==<br />
<br />
* Ogg Audio Profile (audio in Ogg container)<br />
* Applications supporting .oga, .ogv SHOULD support decoding from muxed Ogg streams<br />
* Covers Ogg [[FLAC]], [[Opus]], [[Ghost]], and [[OggPCM]] <br />
* Although they share the same MIME type, Vorbis and Speex use different file extensions.<br />
* SHOULD contain a Skeleton logical bitstream.<br />
* Vorbis and Speex may use .oga, but it is not the prefered method of distributing these files because of backwards-compatibility issues.<br />
<br />
== .ogx - application/ogg ==<br />
<br />
* Ogg Multiplex Profile (anything in [[Ogg]])<br />
* can contain any logical bitstreams multiplexed together in an ogg container<br />
* will replace the .ogg extension from RFC 3534 http://www.ietf.org/rfc/rfc3534.txt<br />
* random multitrack files MUST contain a [[Skeleton]] track to identify all containing logical bitstreams<br />
* apps that identify a logical bitstream which they cannot decode SHOULD ignore it but MAY still decode the ones they can<br />
* thus, e.g. an annodex file can gracefully degrade to .ogx if an app cannot decode [[CMML]] and/or [[Skeleton]]<br />
* USE: application/ogg has been registered, so can be used immediately<br />
<br />
== .spx - audio/ogg ==<br />
<br />
* Ogg Speex Profile<br />
* .spx has traditionally been used for Speex files within Ogg and should be considered for backwards-compatibility<br />
<br />
== .flac - audio/flac ==<br />
<br />
* FLAC in native encapsulation format<br />
<br />
== .anx - application/annodex ==<br />
<br />
* Profile for multiplexed Ogg that includes a skeleton track and at least one CMML logical bitstream<br />
* apps that identify a logical bitstream which they cannot decode SHOULD ignore it but MAY still decode the ones they can<br />
* 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<br />
<br />
== .axa - audio/annodex ==<br />
<br />
* Profile for audio in Annodex <br />
* covers e.g. [[Vorbis]], [[Speex]], [[FLAC]], [[Opus]], [[Ghost]], [[OggPCM]] inside Ogg with Skeleton and CMML<br />
<br />
== .axv - video/annodex ==<br />
<br />
* Profile for video in Annodex <br />
* covers e.g. [[Theora]], Theora + Vorbis, Theora + Speex, Theora + FLAC, [[Dirac]] + Vorbis, [[OggMNG|MNG]] + FLAC, [[OggUVS]] inside Ogg with Skeleton and CMML<br />
<br />
== .xspf - application/xspf+xml ==<br />
<br />
* Profile for XSPF<br />
* Covers [[XSPF]], while being used through XML<br />
* Does not cover [[JSPF]], which is XSPF but on JSON<br />
<br />
== Ogg Kate files - application/kate ==<br />
<br />
* Binary representation of Kate encapsulated in Ogg<br />
* may have a skeleton<br />
* can be used to identify the mime type of the track itself (e.g. in skeleton)<br />
* uses .ogx extension when in a file by itself<br />
* is subdued by the dominant mime type if in a audio or video file to become audio/ogg or video/ogg<br />
<br />
== Codec MIME types ==<br />
<br />
Codecs need their own MIME types for streaming in RTP and to be used in multitrack ogg files using skeleton:<br />
<br />
* audio/vorbis for Vorbis without container<br />
* video/theora for Theora without container<br />
* audio/speex for Speex without container<br />
* audio/flac for FLAC without and in native container<br />
* audio/opus for Opus without container<br />
* text/cmml for CMML without container<br />
* application/kate for the textual representation of Kate (.kate files)</div>Rillianhttps://wiki.xiph.org/index.php?title=Mp4Opus&diff=15001Mp4Opus2014-09-23T19:09:46Z<p>Rillian: Link to Paranoialmaniac's draft</p>
<hr />
<div>{{draft}}<br />
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.<br />
<br />
[http://wiki.multimedia.cx/index.php?title=MP4 MP4] already has support for declaring encoder delay and pre-roll.<br />
<br />
For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.<br />
<br />
For delay, Daemon404 suggested "whatever l-smash maps encoder delay to."<br />
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.<br />
<br />
See also [http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html Paranoialmaniac's draft].<br />
<br />
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.<br />
<br />
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?<br />
<br />
Possible registration process, send an email to http://mp4ra.org/request.html. Possible registrar is 'Opus'.<br />
<br />
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.<br />
<br />
'''Global Header'''<br />
<br />
''AudioRollRecoveryEntry'' - shall have a value of 3840 (80ms * 48k)<br />
<br />
''AudioSampleEntry'' - hardcoded at 16fp<br />
<br />
''descriptor'' - same as ogg rather than as ts, to keep things simple<br />
<br />
''channel count'' - already included <br />
''pre skip'' - already included<br />
<br />
''Gain'' - volume atom? unused in practice - oggheader - not in ts (TODO?)<br />
when you decode samples you're supposed to multiply against this value, so that decoder can apply post volume<br />
Reusing the one in ogg.<br />
<br />
''mapping family'' (with vorbis mapping)<br />
- mono/stereo no channel config<br />
- specify # channel<br />
- map to the # ouput<br />
<br />
audio channel layout https://developer.apple.com/library/mac/documentation/musicaudio/reference/CoreAudioDataTypesRef/Reference/reference.html - too complex<br />
plug it from ogg and put it in our custom atom<br />
<br />
'''Things to put in custom atom'''<br />
- input sr<br />
- output gain<br />
- channel mappaing<br />
- channel count (for backup)<br />
<br />
'''Opus''' is the name of the atom, like in TS<br />
<br />
what about album art? quicktime/mp4/mp3</div>Rillianhttps://wiki.xiph.org/index.php?title=Mp4Opus&diff=15000Mp4Opus2014-09-23T19:07:45Z<p>Rillian: One edit list entry supports both start and end trim.</p>
<hr />
<div>{{draft}}<br />
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.<br />
<br />
[http://wiki.multimedia.cx/index.php?title=MP4 MP4] already has support for declaring encoder delay and pre-roll.<br />
<br />
For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.<br />
<br />
For delay, Daemon404 suggested "whatever l-smash maps encoder delay to."<br />
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.<br />
<br />
<br />
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.<br />
<br />
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?<br />
<br />
Possible registration process, send an email to http://mp4ra.org/request.html. Possible registrar is 'Opus'.<br />
<br />
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.<br />
<br />
'''Global Header'''<br />
<br />
''AudioRollRecoveryEntry'' - shall have a value of 3840 (80ms * 48k)<br />
<br />
''AudioSampleEntry'' - hardcoded at 16fp<br />
<br />
''descriptor'' - same as ogg rather than as ts, to keep things simple<br />
<br />
''channel count'' - already included <br />
''pre skip'' - already included<br />
<br />
''Gain'' - volume atom? unused in practice - oggheader - not in ts (TODO?)<br />
when you decode samples you're supposed to multiply against this value, so that decoder can apply post volume<br />
Reusing the one in ogg.<br />
<br />
''mapping family'' (with vorbis mapping)<br />
- mono/stereo no channel config<br />
- specify # channel<br />
- map to the # ouput<br />
<br />
audio channel layout https://developer.apple.com/library/mac/documentation/musicaudio/reference/CoreAudioDataTypesRef/Reference/reference.html - too complex<br />
plug it from ogg and put it in our custom atom<br />
<br />
'''Things to put in custom atom'''<br />
- input sr<br />
- output gain<br />
- channel mappaing<br />
- channel count (for backup)<br />
<br />
'''Opus''' is the name of the atom, like in TS<br />
<br />
what about album art? quicktime/mp4/mp3</div>Rillianhttps://wiki.xiph.org/index.php?title=Mp4Opus&diff=14779Mp4Opus2014-07-09T17:45:33Z<p>Rillian: Mention edit lists for pre-skip</p>
<hr />
<div>{{draft}}<br />
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.<br />
<br />
MP4 already has support for declaring encoder delay and pre-roll.<br />
<br />
For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.<br />
<br />
For delay, Daemon404 suggested "whatever l-smash maps encoder delay to."<br />
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.<br />
<br />
<br />
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.<br />
<br />
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?</div>Rillianhttps://wiki.xiph.org/index.php?title=Mp4Opus&diff=14778Mp4Opus2014-07-09T17:12:43Z<p>Rillian: fix link</p>
<hr />
<div>{{draft}}<br />
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.<br />
<br />
MP4 already has support for declaring encoder delay and pre-roll.<br />
<br />
For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.<br />
<br />
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.<br />
<br />
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?</div>Rillianhttps://wiki.xiph.org/index.php?title=Mp4Opus&diff=14777Mp4Opus2014-07-09T17:11:51Z<p>Rillian: Things which have come up so far</p>
<hr />
<div>{{draft}}<br />
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.<br />
<br />
MP4 already has support for declaring encoder delay and pre-roll.<br />
<br />
For pre-roll I believe we can use 'AudioRollRecoveryEntry' for pre-roll.<br />
<br />
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.<br />
<br />
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?</div>Rillianhttps://wiki.xiph.org/index.php?title=Mp4Opus&diff=14776Mp4Opus2014-07-09T16:42:41Z<p>Rillian: Start a page collecting ideas for Opus in MP4</p>
<hr />
<div>{{draft}}<br />
This is a draft encapsulation guide for [[Opus]] audio in the mp4 (ISO Base) media container.</div>Rillianhttps://wiki.xiph.org/index.php?title=Daala_Quickstart&diff=14764Daala Quickstart2014-07-04T18:52:03Z<p>Rillian: /* Mac OS X */ Xcode should include git</p>
<hr />
<div>= Getting Started =<br />
<br />
This is a simple guide to getting the code and encoding a simple video.<br />
<br />
== Installation ==<br />
<br />
=== Pre-requisites ===<br />
* Standard build tools (autoconf, automake v1.11 or later, libtool, and a C compiler)<br />
* git<br />
* libogg (v1.3 or later)<br />
* libpng<br />
* libjpeg<br />
* libcheck (v0.9.8 or later, can be skipped if you pass --disable-unit-tests to ./configure)<br />
* libsdl (can by skipped if you pass --disable-player to ./configure)<br />
<br />
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.<br />
<br />
==== Mac OS X ====<br />
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].<br />
<br />
Install [http://brew.sh/ Homebrew]<br />
<br />
Run the following command to install dependencies:<br />
brew install autoconf automake libtool libogg libpng libjpeg check sdl<br />
<br />
=== Installation Procedure ===<br />
<br />
Just run these commands:<br />
<br />
git clone https://git.xiph.org/daala.git<br />
cd daala<br />
./autogen.sh<br />
./configure<br />
make<br />
<br />
Note that the git clone can take several minutes to complete.<br />
<br />
And optionally<br />
<br />
make tools<br />
<br />
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.<br />
<br />
== Encoding a Video ==<br />
<br />
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:<br />
* [https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz Subset 1] (50 images, small training set)<br />
* [https://people.xiph.org/~tterribe/daala/subset2-y4m.tar.gz Subset 2] (1000 images, large training set)<br />
* [https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz Subset 3] (50 images, small testing set)<br />
* [https://people.xiph.org/~tterribe/daala/subset4-y4m.tar.gz Subset 4] (1000 images, large testing set)<br />
<br />
Encode the video:<br />
<br />
./examples/encoder_example -v 30 -k 256 video.y4m -o video.ogv<br />
<br />
where<br />
* video.y4m is the input video you want to encode,<br />
* video.ogv is the name of the encoded video file to output,<br />
* -v specifies the quality (currently from 0 to 511, where 0 is lossless), and<br />
* -k specifies the maximum keyframe interval (this is currently 1 by default, which makes every frame a keyframe).<br />
<br />
== Decoding a Video ==<br />
<br />
Play the video:<br />
<br />
./examples/player_example -p video.ogv<br />
<br />
The -p option starts the player paused. Run<br />
<br />
./examples/player_example --help<br />
<br />
for information on the controls available while playing.<br />
<br />
If you want to use a different player, you can decode the video back to .y4m with<br />
<br />
./examples/dump_video video.ogv -o decoded_video.y4m<br />
<br />
Many other players can play back these .y4m files, and other tools can convert them to various other formats.<br />
<br />
== Using PNG Images ==<br />
<br />
To encode a series of images:<br />
<br />
make tools<br />
./tools/png2y4m video%05d.png -o video.y4m<br />
<br />
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).<br />
<br />
To convert a y4m back to PNGs:<br />
<br />
./tools/y4m2png video.y4m -o video%05d.png<br />
<br />
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.</div>Rillianhttps://wiki.xiph.org/index.php?title=Daala_Quickstart&diff=14763Daala Quickstart2014-07-04T18:51:12Z<p>Rillian: /* Mac OS X */ Mention Xcode</p>
<hr />
<div>= Getting Started =<br />
<br />
This is a simple guide to getting the code and encoding a simple video.<br />
<br />
== Installation ==<br />
<br />
=== Pre-requisites ===<br />
* Standard build tools (autoconf, automake v1.11 or later, libtool, and a C compiler)<br />
* git<br />
* libogg (v1.3 or later)<br />
* libpng<br />
* libjpeg<br />
* libcheck (v0.9.8 or later, can be skipped if you pass --disable-unit-tests to ./configure)<br />
* libsdl (can by skipped if you pass --disable-player to ./configure)<br />
<br />
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.<br />
<br />
==== Mac OS X ====<br />
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].<br />
<br />
Install [http://brew.sh/ Homebrew]<br />
<br />
Run the following command to install dependencies:<br />
brew install autoconf automake libtool git libogg libpng libjpeg check sdl<br />
<br />
=== Installation Procedure ===<br />
<br />
Just run these commands:<br />
<br />
git clone https://git.xiph.org/daala.git<br />
cd daala<br />
./autogen.sh<br />
./configure<br />
make<br />
<br />
Note that the git clone can take several minutes to complete.<br />
<br />
And optionally<br />
<br />
make tools<br />
<br />
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.<br />
<br />
== Encoding a Video ==<br />
<br />
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:<br />
* [https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz Subset 1] (50 images, small training set)<br />
* [https://people.xiph.org/~tterribe/daala/subset2-y4m.tar.gz Subset 2] (1000 images, large training set)<br />
* [https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz Subset 3] (50 images, small testing set)<br />
* [https://people.xiph.org/~tterribe/daala/subset4-y4m.tar.gz Subset 4] (1000 images, large testing set)<br />
<br />
Encode the video:<br />
<br />
./examples/encoder_example -v 30 -k 256 video.y4m -o video.ogv<br />
<br />
where<br />
* video.y4m is the input video you want to encode,<br />
* video.ogv is the name of the encoded video file to output,<br />
* -v specifies the quality (currently from 0 to 511, where 0 is lossless), and<br />
* -k specifies the maximum keyframe interval (this is currently 1 by default, which makes every frame a keyframe).<br />
<br />
== Decoding a Video ==<br />
<br />
Play the video:<br />
<br />
./examples/player_example -p video.ogv<br />
<br />
The -p option starts the player paused. Run<br />
<br />
./examples/player_example --help<br />
<br />
for information on the controls available while playing.<br />
<br />
If you want to use a different player, you can decode the video back to .y4m with<br />
<br />
./examples/dump_video video.ogv -o decoded_video.y4m<br />
<br />
Many other players can play back these .y4m files, and other tools can convert them to various other formats.<br />
<br />
== Using PNG Images ==<br />
<br />
To encode a series of images:<br />
<br />
make tools<br />
./tools/png2y4m video%05d.png -o video.y4m<br />
<br />
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).<br />
<br />
To convert a y4m back to PNGs:<br />
<br />
./tools/y4m2png video.y4m -o video%05d.png<br />
<br />
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.</div>Rillianhttps://wiki.xiph.org/index.php?title=Daala_Quickstart&diff=14719Daala Quickstart2014-06-02T23:16:51Z<p>Rillian: /* Installation Procedure */ Mention our git is slow.</p>
<hr />
<div>= Getting Started =<br />
<br />
This is a simple guide to getting the code and encoding a simple video.<br />
<br />
== Installation ==<br />
<br />
=== Pre-requisites ===<br />
* Standard build tools (autoconf, automake v1.11 or later, libtool, and a C compiler)<br />
* git<br />
* libogg (v1.3 or later)<br />
* libpng<br />
* libjpeg<br />
* libcheck (v0.9.8 or later, can be skipped if you pass --disable-unit-tests to ./configure)<br />
* libsdl (can by skipped if you pass --disable-player to ./configure)<br />
<br />
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.<br />
<br />
=== Installation Procedure ===<br />
<br />
Just run these commands:<br />
<br />
git clone https://git.xiph.org/daala.git<br />
cd daala<br />
./autogen.sh<br />
./configure<br />
make<br />
<br />
Note that the git clone can take several minutes to complete.<br />
<br />
And optionally<br />
<br />
make tools<br />
<br />
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.<br />
<br />
== Encoding a Video ==<br />
<br />
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:<br />
* [https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz Subset 1] (50 images, small training set)<br />
* [https://people.xiph.org/~tterribe/daala/subset2-y4m.tar.gz Subset 2] (1000 images, large training set)<br />
* [https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz Subset 3] (50 images, small testing set)<br />
* [https://people.xiph.org/~tterribe/daala/subset4-y4m.tar.gz Subset 4] (1000 images, large testing set)<br />
<br />
Encode the video:<br />
<br />
./examples/encoder_example -v 30 -k 256 video.y4m -o video.ogv<br />
<br />
where<br />
* video.y4m is the input video you want to encode,<br />
* video.ogv is the name of the encoded video file to output,<br />
* -v specifies the quality (currently from 0 to 511, where 0 is lossless), and<br />
* -k specifies the maximum keyframe interval (this is currently 1 by default, which makes every frame a keyframe).<br />
<br />
== Decoding a Video ==<br />
<br />
Play the video:<br />
<br />
./examples/player_example -p video.ogv<br />
<br />
The -p option starts the player paused. Run<br />
<br />
./examples/player_example --help<br />
<br />
for information on the controls available while playing.<br />
<br />
If you want to use a different player, you can decode the video back to .y4m with<br />
<br />
./examples/dump_video video.ogv -o decoded_video.y4m<br />
<br />
Many other players can play back these .y4m files, and other tools can convert them to various other formats.<br />
<br />
== Using PNG Images ==<br />
<br />
To encode a series of images:<br />
<br />
make tools<br />
./tools/png2y4m video%05d.png -o video.y4m<br />
<br />
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).<br />
<br />
To convert a y4m back to PNGs:<br />
<br />
./tools/y4m2png video.y4m -o video%05d.png<br />
<br />
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.</div>Rillianhttps://wiki.xiph.org/index.php?title=Daala_Quickstart&diff=14718Daala Quickstart2014-06-02T23:05:29Z<p>Rillian: /* Installation Procedure */ The ssh host string only supports people with commit access. Better to start with a read-only https url.</p>
<hr />
<div>= Getting Started =<br />
<br />
This is a simple guide to getting the code and encoding a simple video.<br />
<br />
== Installation ==<br />
<br />
=== Pre-requisites ===<br />
* Standard build tools (autoconf, automake v1.11 or later, libtool, and a C compiler)<br />
* git<br />
* libogg (v1.3 or later)<br />
* libpng<br />
* libjpeg<br />
* libcheck (v0.9.8 or later, can be skipped if you pass --disable-unit-tests to ./configure)<br />
* libsdl (can by skipped if you pass --disable-player to ./configure)<br />
<br />
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.<br />
<br />
=== Installation Procedure ===<br />
<br />
Just run these commands:<br />
<br />
git clone https://git.xiph.org/daala.git<br />
cd daala<br />
./autogen.sh<br />
./configure<br />
make<br />
<br />
And optionally<br />
<br />
make tools<br />
<br />
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.<br />
<br />
== Encoding a Video ==<br />
<br />
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:<br />
* [https://people.xiph.org/~tterribe/daala/subset1-y4m.tar.gz Subset 1] (50 images, small training set)<br />
* [https://people.xiph.org/~tterribe/daala/subset2-y4m.tar.gz Subset 2] (1000 images, large training set)<br />
* [https://people.xiph.org/~tterribe/daala/subset3-y4m.tar.gz Subset 3] (50 images, small testing set)<br />
* [https://people.xiph.org/~tterribe/daala/subset4-y4m.tar.gz Subset 4] (1000 images, large testing set)<br />
<br />
Encode the video:<br />
<br />
./examples/encoder_example -v 30 -k 256 video.y4m -o video.ogv<br />
<br />
where<br />
* video.y4m is the input video you want to encode,<br />
* video.ogv is the name of the encoded video file to output,<br />
* -v specifies the quality (currently from 0 to 511, where 0 is lossless), and<br />
* -k specifies the maximum keyframe interval (this is currently 1 by default, which makes every frame a keyframe).<br />
<br />
== Decoding a Video ==<br />
<br />
Play the video:<br />
<br />
./examples/player_example -p video.ogv<br />
<br />
The -p option starts the player paused. Run<br />
<br />
./examples/player_example --help<br />
<br />
for information on the controls available while playing.<br />
<br />
If you want to use a different player, you can decode the video back to .y4m with<br />
<br />
./examples/dump_video video.ogv -o decoded_video.y4m<br />
<br />
Many other players can play back these .y4m files, and other tools can convert them to various other formats.<br />
<br />
== Using PNG Images ==<br />
<br />
To encode a series of images:<br />
<br />
make tools<br />
./tools/png2y4m video%05d.png -o video.y4m<br />
<br />
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).<br />
<br />
To convert a y4m back to PNGs:<br />
<br />
./tools/y4m2png video.y4m -o video%05d.png<br />
<br />
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.</div>Rillianhttps://wiki.xiph.org/index.php?title=DaalaRoadmap&diff=14688DaalaRoadmap2014-05-18T16:48:55Z<p>Rillian: /* Daala Planning */ Link to etherpad for newer information.</p>
<hr />
<div>== Daala Planning ==<br />
<br />
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!<br />
<br />
=== Plans for 2014 ===<br />
<br />
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.<br />
<br />
=== Plans for September, 2013 to March, 2014 ===<br />
<br />
==== Improve existing techniques ==== <br />
<br />
Examining and significantly modifying some of the basic coding tools within Daala to improve efficiency and quality:<br />
<br />
1) Lapped Transforms<br />
* https://people.xiph.org/~xiphmont/demo/daala/demo1.shtml<br />
* http://thanglong.ece.jhu.edu/Tran/Pub/prepost.pdf<br />
* https://research.microsoft.com/pubs/102075/malvar_elt_tsp1192.pdf<br />
<br />
2) Frequency Domain Intraprediction <br />
* https://people.xiph.org/~xiphmont/demo/daala/demo2.shtml<br />
<br />
3) Time/Frequency resolution switching <br />
* https://people.xiph.org/~xiphmont/demo/daala/demo3.shtml<br />
<br />
4) Chroma from Luma<br />
* http://people.xiph.org/~xiphmont/demo/daala/demo4.shtml<br />
<br />
5) Motion Compensation tools<br />
<br />
==== Research new techniques ====<br />
<br />
Investigate the following to see if they should be adopted into Daala:<br />
<br />
1) Edge-directed Interpolation <br />
*http://elynxsdk.free.fr/ext-docs/Demosaicing/more/news0/New%20Edge-Directed%20Interpolation.pdf<br />
<br />
2) Multi-frame Motion Compensation<br />
<br />
==== Testing tools ====<br />
<br />
1) Experiment with command-line encode/decode/performance tools<br />
* Help people try the codec<br />
* Self-testing<br />
* Improvement metrics for casual contributors to verify changes<br />
<br />
2) Prototype RTP in GIPS/webrtc.org/browser code<br />
<br />
3) Prototype HTTP streaming.<br />
<br />
=== Plans for March, 2014 to September, 2014 ===<br />
<br />
<br />
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)<br />
<br />
By September, 2014: Be able to show significant quality improvements compared to Daala's performance today (September, 2013).<br />
<br />
=== Progress and planning tools we'll use along the way: ===<br />
* Every 6-8 weeks the team will report on what he has accomplished.<br />
* Every month the team will create a detailed task list of what they plan to do for that month.</div>Rillianhttps://wiki.xiph.org/index.php?title=Daala_on_Wheels&diff=14687Daala on Wheels2014-05-18T16:44:20Z<p>Rillian: /* Work in progress */ Link to etherpad roadmap</p>
<hr />
<div>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.<br />
<br />
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. <br />
<br />
See also: [https://xiph.org/daala/ https://xiph.org/daala/]<br />
<br />
== Work in progress ==<br />
<br />
* [https://daala.etherpad.mozilla.org/daala-plan-2014 2014 Roadmap]<br />
* [[DaalaRoadmap]]<br />
* [https://daala.etherpad.mozilla.org/workweek-201402 2014 February meetup]<br />
* [https://daala.etherpad.mozilla.org/daala-meetup 2013 November meetup]<br />
* [https://daala.etherpad.mozilla.org/coding-party-201309 2013 September code party]<br />
* [https://daala.etherpad.mozilla.org/august-todo August task tracking]<br />
* [https://daala.etherpad.mozilla.org/july-todo July tasks]<br />
* [https://daala.etherpad.mozilla.org/june-todo June tasks]<br />
<br />
== Weekly meetings ==<br />
<br />
We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
* [[DaalaMeeting20140128|2014 January 28]] - pvq, work week<br />
* [[DaalaMeeting20140211|2014 February 11]] - 32x32, activity masking, current issues<br />
* [[DaalaMeeting20140218|2014 February 18]] - input scaling, prediction error<br />
* [[DaalaMeeting20140225|2014 February 25]] - det1, pvq, fastssim<br />
* [[DaalaMeeting20140304|2014 March 4]] - det1, quant matrix, metrics<br />
* [[DaalaMeeting20140318|2014 March 18]] - det1, fastssim, activity masking<br />
* [[DaalaMeeting20140401|2014 April 1]] - crushing jpeg, pvq<br />
* [[DaalaMeeting20140408|2014 April 8]] - reviews, pvq presentation<br />
* [[DaalaMeeting20140415|2014 April 15]] - pvq experiments, activity masking<br />
* [[DaalaMeeting20140422|2014 April 22]] - block size switching, gpu jpeg<br />
* [[DaalaMeeting20140506|2014 May 6]] - workweek debrief, trained vq<br />
<br />
= Techniques =<br />
<br />
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.<br />
<br />
Other components which have been discussed include:<br />
<br />
==Techniques applicable to all frame types==<br />
* Multisymbol arithmetic coding <br />
** Timothy has some trial code showing speed-up proportional to the number of bits coded at once. (ec_test.c)<br />
* Mode prediction using the previously decoded data, e.g. coding the mode using a probability function derived from trained predictors on the surrounding blocks. <br />
** 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.<br />
* Explore legendre polynomial basis transforms instead of DCT<br />
** May have better perceptual properties and/or result in 'less compromised' efficient implementations. <br />
* Coefficient domain prediction to allow efficient energy preserving quantization.<br />
* Variable partition size/shape and the use of good predictors appears to remove most of the benefit of directional transforms.<br />
** Perhaps 45deg is still useful?<br />
** How does this change with partition sizes? Directional transforms are clearly not that useful with 4x4. <br />
* 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.<br />
* Perturbed quantization mode-signalling has been discussed but mostly laughed at. ;) <br />
* Special block modes well suited to solid color/cartoon like content— avoiding ringing.<br />
** Are pixel prediction modes too slow?<br />
* In general— what markov random field techniques can be applied with acceptable performance. Any?<br />
* Designed for parallel encode and decode within each frame<br />
** Important because<br />
*** the proposed techniques need a lot more CPU than H.264 and VP8 for both encode and decode<br />
*** Moore's law for single-threaded throughput is dead. Future hardware is all multicore/GPU.<br />
** Implies<br />
*** Getting the order of application right for the lapping filters.<br />
*** Mandatory slicing? Maybe some kind of multilevel entropy coding to reduce redundancy between slices while minimizing the single-threaded portion of decode.<br />
<br />
* Using PVQ and energy conservation: see http://jmvalin.ca/video/video_pvq_v3.pdf<br />
<br />
==Techniques applicable to inter frames==<br />
* 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).<br />
** 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.<br />
* 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.<br />
** 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.<br />
** 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.<br />
* 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)<br />
<br />
==Basic features==<br />
* YUV 4:4:4, 4:2:2 , 4:2:0 subsamplings, 8-bit, 10bit.<br />
* Alpha channel — need testing material!<br />
* 8-bit RGB compatible mode? (e.g. YCoCg, internally or at least flagging for it)<br />
* Efficient 3D? — need testing material!<br />
* Lossless?<br />
** 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<br />
* Good support for decode side droppable frames?<br />
** Hopefully the referencing structure will be flexible enough to enable this even if it's not an intentional feature.<br />
<br />
==Frills==<br />
* Optionally storing a checksum of the expected decoded frame for decoder/encoder mismatch detection.<br />
* Expose the number of referential descendants of a given frame (or even the whole reference DAG) for most efficient allocation of FEC.<br />
<br />
==Wingdings==<br />
Crazy crap that might be interesting or at least fun to make fun of... <br />
* >10bit?<br />
** Use cases don't seem well enough defined yet. Significant complexity. Any prospective hardware developer may hire assassins.<br />
** 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.<br />
**# 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.<br />
**# 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.<br />
* 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.<br />
** 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.<br />
* 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.<br />
** 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?<br />
** 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.<br />
** Use of explicitly (rather than staged) super-resolution and/or deeper references may make this functionality unattractive due to increased overhead.<br />
* 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.<br />
** Complicates making the complexity bounded. No Sufficiently Advanced™ encoder likely to ever exist. But perhaps the station id/advertising uses fully justify this.<br />
** Could be done externally to the video codec, but if so it's no likely to be useful for anyone ever.<br />
* 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.<br />
* 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.<br />
* Parametric decode-side blur.<br />
** Symmetrical blur in regions that are smooth on scales longer than the block size. Could be signaled or derived from observed DC values.<br />
** 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).<br />
* Fancy block property prediction. (Not clear how these prediction interact with intra pred)<br />
** 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.<br />
** 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.<br />
<br />
==Negative results==<br />
<br />
* Using Kurtosis for detecting text in a frame<br />
** The idea was to detect a Bernouilli distribution but it's not robust and too noisy</div>Rillianhttps://wiki.xiph.org/index.php?title=OggOpusImplementation&diff=14489OggOpusImplementation2014-02-26T00:37:27Z<p>Rillian: /* Chrome */ gain and end trimming seem to respected now.</p>
<hr />
<div>== Implementation Status ==<br />
<br />
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.<br />
<br />
What follows is a brief summary of major implementations of the draft, and their status.<br />
This is intended to help understand the status of each portion of the draft, per [https://tools.ietf.org/html/rfc6982 RFC 6982].<br />
<br />
=== opus-tools ===<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://git.xiph.org/?p=opus-tools.git<br />
* http://www.opus-codec.org/downloads/<br />
<br />
=== opusfile ===<br />
<br />
The opusfile library is a separate implementation of this draft as a helper library for demuxing and decoding.<br />
Like opus-tools, it supports metadata, multichannel, start and end trimming, the gain field, live streams, and chained files.<br />
Its primary focus is efficient seeking, including over HTTP(S) and in chained streams.<br />
It currently does not create Ogg Opus files.<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://git.xiph.org/?p=opusfile.git<br />
* http://www.opus-codec.org/downloads/<br />
<br />
=== Firefox ===<br />
<br />
The Firefox web browser is a widely deployed implementation of this draft.<br />
Basic playback support with the HTML5 &lt;audio&gt; element, including start and end trimming, the gain field, live streams, multiplexing with other streams (for, e.g., the &lt;video&gt; tag), and seeking, was added in Firefox 15, in production release starting August 28, 2012.<br />
Multichannel support was added in Firefox 17, in production release starting November 20, 2012.<br />
Metadata support was added in Firefox 18, in production release starting January 8, 2013.<br />
Chained file support (as streams only, with seeking disabled) was added in Firefox 20, in production release starting April 2, 2013.<br />
Encoding support was added in Firefox 26, in production release starting December 10, 2013.<br />
<br />
This implementation is open source.<br />
<br />
* https://mozilla.org/firefox/<br />
* https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=674225<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=748144<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=778050<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=455165<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=842243<br />
<br />
=== Chrome ===<br />
<br />
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.<br />
This implementation currently does not support chained files.<br />
Prior to M33 support required passing --enable-opus-playback on the command line when invoking the executable.<br />
<br />
This implementation is based on open source code in Chromium, Blink, and FFmpeg.<br />
<br />
* https://www.google.com/intl/en/chrome/browser/<br />
* https://www.google.com/intl/en/chrome/browser/canary.html<br />
* https://code.google.com/p/chromium/issues/detail?id=104241<br />
<br />
=== GStreamer ===<br />
<br />
The GStreamer media framework includes an implementation of this draft.<br />
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, multiplexing with other streams (e.g., video), and seeking.<br />
Support was first added in early 2011, and is part of the 0.11 and 1.0.x releases.<br />
The code implementing this draft is in the gst-plugins-bad collection, which generally indicates unsupported and/or experimental code, despite its release status.<br />
<br />
This implementation is open source.<br />
<br />
* http://gstreamer.net/<br />
* http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/<br />
<br />
=== FFmpeg ===<br />
<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://ffmpeg.org/<br />
<br />
=== libav ===<br />
<br />
The development repository for libav implements this draft, similar to FFmpeg.<br />
<br />
This implementation is open source.<br />
<br />
* https://libav.org/<br />
<br />
=== VLC ===<br />
<br />
VLC is another widely deployed implementation of demuxing, decoding, and playback support for this draft.<br />
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).<br />
Opus support was added in version 2.0.4, released on October 18, 2012.<br />
<br />
This implementation is open source.<br />
<br />
* https://www.videolan.org/vlc/<br />
* https://git.videolan.org/?p=vlc.git<br />
* https://trac.videolan.org/vlc/ticket/7185<br />
<br />
=== foobar2000 ===<br />
<br />
A popular Windows application, foobar2000 implements read, write, and playback support for this draft.<br />
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, and seeking.<br />
Opus support was added in version 1.1.14, released on August 17, 2012.<br />
Encoding support is implemented using opusenc from opus-tools.<br />
<br />
This implementation is closed source.<br />
<br />
* http://www.foobar2000.org/<br />
<br />
=== Rockbox ===<br />
<br />
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.<br />
It supports metadata, start and end trimming, the gain field, and seeking.<br />
It does not currently support multichannel or chained files.<br />
<br />
This implementation is open source.<br />
<br />
* http://www.rockbox.org/<br />
* http://git.rockbox.org/?p=rockbox.git<br />
* http://gerrit.rockbox.org/r/#/c/300/<br />
<br />
=== Youki3 ===<br />
<br />
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].<br />
<br />
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<br />
<br />
* https://plus.google.com/communities/102114949476184273984<br />
<br />
The app source is currently closed, however since it utilizes LibVLC for playback, the respective source is open.</div>Rillianhttps://wiki.xiph.org/index.php?title=OggOpusImplementation&diff=14488OggOpusImplementation2014-02-26T00:18:15Z<p>Rillian: /* Chrome */ Chrome 33 is released</p>
<hr />
<div>== Implementation Status ==<br />
<br />
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.<br />
<br />
What follows is a brief summary of major implementations of the draft, and their status.<br />
This is intended to help understand the status of each portion of the draft, per [https://tools.ietf.org/html/rfc6982 RFC 6982].<br />
<br />
=== opus-tools ===<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://git.xiph.org/?p=opus-tools.git<br />
* http://www.opus-codec.org/downloads/<br />
<br />
=== opusfile ===<br />
<br />
The opusfile library is a separate implementation of this draft as a helper library for demuxing and decoding.<br />
Like opus-tools, it supports metadata, multichannel, start and end trimming, the gain field, live streams, and chained files.<br />
Its primary focus is efficient seeking, including over HTTP(S) and in chained streams.<br />
It currently does not create Ogg Opus files.<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://git.xiph.org/?p=opusfile.git<br />
* http://www.opus-codec.org/downloads/<br />
<br />
=== Firefox ===<br />
<br />
The Firefox web browser is a widely deployed implementation of this draft.<br />
Basic playback support with the HTML5 &lt;audio&gt; element, including start and end trimming, the gain field, live streams, multiplexing with other streams (for, e.g., the &lt;video&gt; tag), and seeking, was added in Firefox 15, in production release starting August 28, 2012.<br />
Multichannel support was added in Firefox 17, in production release starting November 20, 2012.<br />
Metadata support was added in Firefox 18, in production release starting January 8, 2013.<br />
Chained file support (as streams only, with seeking disabled) was added in Firefox 20, in production release starting April 2, 2013.<br />
Encoding support was added in Firefox 26, in production release starting December 10, 2013.<br />
<br />
This implementation is open source.<br />
<br />
* https://mozilla.org/firefox/<br />
* https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=674225<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=748144<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=778050<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=455165<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=842243<br />
<br />
=== Chrome ===<br />
<br />
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.<br />
This implementation currently does not support end trimming, the gain tag, or chained files.<br />
Prior to M33 support required passing --enable-opus-playback on the command line when invoking the executable.<br />
<br />
This implementation is based on open source code in Chromium, Blink, and FFmpeg.<br />
<br />
* https://www.google.com/intl/en/chrome/browser/<br />
* https://www.google.com/intl/en/chrome/browser/canary.html<br />
* https://code.google.com/p/chromium/issues/detail?id=104241<br />
<br />
=== GStreamer ===<br />
<br />
The GStreamer media framework includes an implementation of this draft.<br />
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, multiplexing with other streams (e.g., video), and seeking.<br />
Support was first added in early 2011, and is part of the 0.11 and 1.0.x releases.<br />
The code implementing this draft is in the gst-plugins-bad collection, which generally indicates unsupported and/or experimental code, despite its release status.<br />
<br />
This implementation is open source.<br />
<br />
* http://gstreamer.net/<br />
* http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/<br />
<br />
=== FFmpeg ===<br />
<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://ffmpeg.org/<br />
<br />
=== libav ===<br />
<br />
The development repository for libav implements this draft, similar to FFmpeg.<br />
<br />
This implementation is open source.<br />
<br />
* https://libav.org/<br />
<br />
=== VLC ===<br />
<br />
VLC is another widely deployed implementation of demuxing, decoding, and playback support for this draft.<br />
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).<br />
Opus support was added in version 2.0.4, released on October 18, 2012.<br />
<br />
This implementation is open source.<br />
<br />
* https://www.videolan.org/vlc/<br />
* https://git.videolan.org/?p=vlc.git<br />
* https://trac.videolan.org/vlc/ticket/7185<br />
<br />
=== foobar2000 ===<br />
<br />
A popular Windows application, foobar2000 implements read, write, and playback support for this draft.<br />
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, and seeking.<br />
Opus support was added in version 1.1.14, released on August 17, 2012.<br />
Encoding support is implemented using opusenc from opus-tools.<br />
<br />
This implementation is closed source.<br />
<br />
* http://www.foobar2000.org/<br />
<br />
=== Rockbox ===<br />
<br />
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.<br />
It supports metadata, start and end trimming, the gain field, and seeking.<br />
It does not currently support multichannel or chained files.<br />
<br />
This implementation is open source.<br />
<br />
* http://www.rockbox.org/<br />
* http://git.rockbox.org/?p=rockbox.git<br />
* http://gerrit.rockbox.org/r/#/c/300/<br />
<br />
=== Youki3 ===<br />
<br />
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].<br />
<br />
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<br />
<br />
* https://plus.google.com/communities/102114949476184273984<br />
<br />
The app source is currently closed, however since it utilizes LibVLC for playback, the respective source is open.</div>Rillianhttps://wiki.xiph.org/index.php?title=OggOpusImplementation&diff=14441OggOpusImplementation2014-02-07T22:46:10Z<p>Rillian: /* Chrome */ refer to chrome as widely distributed, even though M33 is still in beta.</p>
<hr />
<div>== Implementation Status ==<br />
<br />
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.<br />
<br />
What follows is a brief summary of major implementations of the draft, and their status.<br />
This is intended to help understand the status of each portion of the draft, per [https://tools.ietf.org/html/rfc6982 RFC 6982].<br />
<br />
=== opus-tools ===<br />
<br />
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.<br />
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.<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://git.xiph.org/?p=opus-tools.git<br />
* http://www.opus-codec.org/downloads/<br />
<br />
=== opusfile ===<br />
<br />
The opusfile library is a separate implementation of this draft as a helper library for demuxing and decoding.<br />
Like opus-tools, it supports metadata, multichannel, start and end trimming, the gain field, live streams, and chained files.<br />
Its primary focus is efficient seeking, including over HTTP(S) and in chained streams.<br />
It currently does not create Ogg Opus files.<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://git.xiph.org/?p=opusfile.git<br />
* http://www.opus-codec.org/downloads/<br />
<br />
=== Firefox ===<br />
<br />
The Firefox web browser is a widely deployed implementation of this draft.<br />
Basic playback support with the HTML5 &lt;audio&gt; element, including start and end trimming, the gain field, live streams, multiplexing with other streams (for, e.g., the &lt;video&gt; tag), and seeking, was added in Firefox 15, in production release starting August 28, 2012.<br />
Multichannel support was added in Firefox 17, in production release starting November 20, 2012.<br />
Metadata support was added in Firefox 18, in production release starting January 8, 2013.<br />
Chained file support (as streams only, with seeking disabled) was added in Firefox 20, in production release starting April 2, 2013.<br />
Encoding support was added in Firefox 26, in production release starting December 10, 2013.<br />
<br />
This implementation is open source.<br />
<br />
* https://mozilla.org/firefox/<br />
* https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=674225<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=748144<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=778050<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=455165<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=842243<br />
<br />
=== Chrome ===<br />
<br />
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.<br />
This implementation currently does not support end trimming, the gain tag, or chained files.<br />
Prior to M33 support required passing --enable-opus-playback on the command line when invoking the executable.<br />
<br />
This implementation is based on open source code in Chromium, Blink, and FFmpeg.<br />
<br />
* https://www.google.com/intl/en/chrome/browser/<br />
* https://www.google.com/intl/en/chrome/browser/canary.html<br />
* https://code.google.com/p/chromium/issues/detail?id=104241<br />
<br />
=== GStreamer ===<br />
<br />
The GStreamer media framework includes an implementation of this draft.<br />
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, multiplexing with other streams (e.g., video), and seeking.<br />
Support was first added in early 2011, and is part of the 0.11 and 1.0.x releases.<br />
The code implementing this draft is in the gst-plugins-bad collection, which generally indicates unsupported and/or experimental code, despite its release status.<br />
<br />
This implementation is open source.<br />
<br />
* http://gstreamer.net/<br />
* http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/<br />
<br />
=== FFmpeg ===<br />
<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://ffmpeg.org/<br />
<br />
=== libav ===<br />
<br />
The development repository for libav implements this draft, similar to FFmpeg.<br />
<br />
This implementation is open source.<br />
<br />
* https://libav.org/<br />
<br />
=== VLC ===<br />
<br />
VLC is another widely deployed implementation of demuxing, decoding, and playback support for this draft.<br />
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).<br />
Opus support was added in version 2.0.4, released on October 18, 2012.<br />
<br />
This implementation is open source.<br />
<br />
* https://www.videolan.org/vlc/<br />
* https://git.videolan.org/?p=vlc.git<br />
* https://trac.videolan.org/vlc/ticket/7185<br />
<br />
=== foobar2000 ===<br />
<br />
A popular Windows application, foobar2000 implements read, write, and playback support for this draft.<br />
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, and seeking.<br />
Opus support was added in version 1.1.14, released on August 17, 2012.<br />
Encoding support is implemented using opusenc from opus-tools.<br />
<br />
This implementation is closed source.<br />
<br />
* http://www.foobar2000.org/<br />
<br />
=== Rockbox ===<br />
<br />
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.<br />
It supports metadata, start and end trimming, the gain field, and seeking.<br />
It does not currently support multichannel or chained files.<br />
<br />
This implementation is open source.<br />
<br />
* http://www.rockbox.org/<br />
* http://git.rockbox.org/?p=rockbox.git<br />
* http://gerrit.rockbox.org/r/#/c/300/</div>Rillianhttps://wiki.xiph.org/index.php?title=Daala_on_Wheels&diff=14437Daala on Wheels2014-02-03T16:32:38Z<p>Rillian: /* Work in progress */ new code party links</p>
<hr />
<div>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.<br />
<br />
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. <br />
<br />
See also: [https://xiph.org/daala/ https://xiph.org/daala/]<br />
<br />
== Work in progress ==<br />
<br />
* [[DaalaRoadmap]]<br />
* [https://daala.etherpad.mozilla.org/workweek-201402 2014 February meetup]<br />
* [https://daala.etherpad.mozilla.org/daala-meetup 2013 November meetup]<br />
* [https://daala.etherpad.mozilla.org/coding-party-201309 2013 September code party]<br />
* [https://daala.etherpad.mozilla.org/august-todo August task tracking]<br />
* [https://daala.etherpad.mozilla.org/july-todo July tasks]<br />
* [https://daala.etherpad.mozilla.org/june-todo June tasks]<br />
<br />
== Weekly meetings ==<br />
<br />
We've been having weekly progress meetings on mumble.<br />
<br />
* 2012 June 4 [https://people.xiph.org/~giles/2012/daala_20120604.txt minutes] (actually a work week)<br />
* 2012 June 22 [https://people.xiph.org/~giles/2012/daala_20120622.txt minutes]<br />
* 2012 June 29 [https://people.xiph.org/~giles/2012/daala_20120629.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120629.opus recording]<br />
* 2012 July 6 [https://people.xiph.org/~giles/2012/daala_20120706.txt minutes]<br />
* 2012 July 13 [https://people.xiph.org/~giles/2012/daala_20120713.txt minutes]<br />
* 2012 July 20 [https://people.xiph.org/~giles/2012/daala_20120720.txt minutes]<br />
* 2012 July 27 [https://people.xiph.org/~giles/2012/daala_20120727.txt minutes]<br />
* 2012 August 3 [https://people.xiph.org/~giles/2012/daala_20120803.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120803.opus recording]<br />
* 2012 August 10 [https://people.xiph.org/~giles/2012/daala_20120810.txt minutes]<br />
* 2012 August 17 - no meeting<br />
* 2012 August 24 - [https://people.xiph.org/~giles/2012/daala_20120824.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120824.opus recording]<br />
* 2012 August 31 - no meeting<br />
* 2012 September 7 - no meeting<br />
* 2012 September 14 - no meeting<br />
* 2012 September 21 - [https://people.xiph.org/~giles/2012/daala_20120921.txt minutes]<br />
* 2012 September 28 - [https://people.xiph.org/~giles/2012/daala_20120928.txt minutes] [https://people.xiph.org/~giles/2012/daala_20120928.opus recording]<br />
* 2012 October 5 - [https://people.xiph.org/~giles/2012/daala_20121005.opus recording]<br />
* 20120 October 26 - <br />
* 2012 Novemeber 2 - no meeting<br />
* 2012 December 7 - [https://people.xiph.org/~giles/2012/daala_20121207.txt minutes]<br />
* [[DaalaMeeting20130911|2013 September 11]] - logistics, status updates, coding party agenda<br />
* [[DaalaMeeting20130917|2013 September 17]] - summit plans, research talks, coding party agenda, monty's TF ideas<br />
* [[DaalaMeeting20130924|2013 September 24]] - training results, 32x32 code, and 2nd stage TF<br />
* [[DaalaMeeting20131008|2013 October 8]] - pvq status, training, chroma from luma<br />
* [[DaalaMeeting20131022|2013 October 22]] - even/odd quantizer, determinant 1, IETF, chroma from luma<br />
* [[DaalaMeeting20131029|2013 October 29]] - gstreamer conf, ietf, chroma from luma<br />
* [[DaalaMeeting20131112|2013 November 12]] - chroma from luma, pvq<br />
* [[DaalaMeeting20131203|2013 December 3]] - chroma from luma, pvq, misc<br />
* [[DaalaMeeting20131217|2013 December 17]] - luma intraprediction, pvq decoder, interns<br />
* [[DaalaMeeting20140107|2014 January 07]] - reviews, pvq projects, and det1<br />
* [[DaalaMeeting20140114|2014 January 14]] - pvq, det1, new projects<br />
* [[DaalaMeeting20140121|2014 January 21]] - project planning<br />
<br />
= Techniques =<br />
<br />
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.<br />
<br />
Other components which have been discussed include:<br />
<br />
==Techniques applicable to all frame types==<br />
* Multisymbol arithmetic coding <br />
** Timothy has some trial code showing speed-up proportional to the number of bits coded at once. (ec_test.c)<br />
* Mode prediction using the previously decoded data, e.g. coding the mode using a probability function derived from trained predictors on the surrounding blocks. <br />
** 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.<br />
* Explore legendre polynomial basis transforms instead of DCT<br />
** May have better perceptual properties and/or result in 'less compromised' efficient implementations. <br />
* Coefficient domain prediction to allow efficient energy preserving quantization.<br />
* Variable partition size/shape and the use of good predictors appears to remove most of the benefit of directional transforms.<br />
** Perhaps 45deg is still useful?<br />
** How does this change with partition sizes? Directional transforms are clearly not that useful with 4x4. <br />
* 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.<br />
* Perturbed quantization mode-signalling has been discussed but mostly laughed at. ;) <br />
* Special block modes well suited to solid color/cartoon like content— avoiding ringing.<br />
** Are pixel prediction modes too slow?<br />
* In general— what markov random field techniques can be applied with acceptable performance. Any?<br />
* Designed for parallel encode and decode within each frame<br />
** Important because<br />
*** the proposed techniques need a lot more CPU than H.264 and VP8 for both encode and decode<br />
*** Moore's law for single-threaded throughput is dead. Future hardware is all multicore/GPU.<br />
** Implies<br />
*** Getting the order of application right for the lapping filters.<br />
*** Mandatory slicing? Maybe some kind of multilevel entropy coding to reduce redundancy between slices while minimizing the single-threaded portion of decode.<br />
<br />
* Using PVQ and energy conservation: see http://jmvalin.ca/video/video_pvq_v3.pdf<br />
<br />
==Techniques applicable to inter frames==<br />
* 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).<br />
** 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.<br />
* 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.<br />
** 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.<br />
** 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.<br />
* 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)<br />
<br />
==Basic features==<br />
* YUV 4:4:4, 4:2:2 , 4:2:0 subsamplings, 8-bit, 10bit.<br />
* Alpha channel — need testing material!<br />
* 8-bit RGB compatible mode? (e.g. YCoCg, internally or at least flagging for it)<br />
* Efficient 3D? — need testing material!<br />
* Lossless?<br />
** 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<br />
* Good support for decode side droppable frames?<br />
** Hopefully the referencing structure will be flexible enough to enable this even if it's not an intentional feature.<br />
<br />
==Frills==<br />
* Optionally storing a checksum of the expected decoded frame for decoder/encoder mismatch detection.<br />
* Expose the number of referential descendants of a given frame (or even the whole reference DAG) for most efficient allocation of FEC.<br />
<br />
==Wingdings==<br />
Crazy crap that might be interesting or at least fun to make fun of... <br />
* >10bit?<br />
** Use cases don't seem well enough defined yet. Significant complexity. Any prospective hardware developer may hire assassins.<br />
** 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.<br />
**# 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.<br />
**# 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.<br />
* 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.<br />
** 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.<br />
* 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.<br />
** 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?<br />
** 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.<br />
** Use of explicitly (rather than staged) super-resolution and/or deeper references may make this functionality unattractive due to increased overhead.<br />
* 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.<br />
** Complicates making the complexity bounded. No Sufficiently Advanced™ encoder likely to ever exist. But perhaps the station id/advertising uses fully justify this.<br />
** Could be done externally to the video codec, but if so it's no likely to be useful for anyone ever.<br />
* 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.<br />
* 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.<br />
* Parametric decode-side blur.<br />
** Symmetrical blur in regions that are smooth on scales longer than the block size. Could be signaled or derived from observed DC values.<br />
** 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).<br />
* Fancy block property prediction. (Not clear how these prediction interact with intra pred)<br />
** 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.<br />
** 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.<br />
<br />
==Negative results==<br />
<br />
* Using Kurtosis for detecting text in a frame<br />
** The idea was to detect a Bernouilli distribution but it's not robust and too noisy</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14429OpusTodo2014-01-27T16:50:22Z<p>Rillian: /* Experiments */ I believe these branches are obsolete post-1.1</p>
<hr />
<div>== For 1.1.1 ==<br />
* Unconstrained SILK VBR<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* 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), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* Port opusdec to libopusfile/libopusurl.<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** 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<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge MIPS optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14428OpusTodo2014-01-27T16:49:42Z<p>Rillian: /* Opus-tools */ mention opusfile->opusdec</p>
<hr />
<div>== For 1.1.1 ==<br />
* Unconstrained SILK VBR<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* 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), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* Port opusdec to libopusfile/libopusurl.<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** 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<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge MIPS optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Rillianhttps://wiki.xiph.org/index.php?title=OpusTodo&diff=14427OpusTodo2014-01-27T16:47:36Z<p>Rillian: updates on things I know we've done</p>
<hr />
<div>== For 1.1.1 ==<br />
* Unconstrained SILK VBR<br />
<br />
== Spec ==<br />
* Ogg mapping. See [[http://tools.ietf.org/html/draft-ietf-codec-oggopus IETF draft]]<br />
* Matroska mapping. See: [[MatroskaOpus]] And firefox/ffmpeg implementation<br />
* RTP payload format See [[http://tools.ietf.org/html/draft-spittka-payload-rtp-opus IETF draft]]<br />
<br />
== Website ==<br />
* 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), ... <br />
* Promotional material (some nice free or Public domain sounds in Opus format)<br />
<br />
== Other ==<br />
<br />
* Oggz-validate (should also validate opus toc)<br />
<br />
== Opus-tools ==<br />
* A simple real time streaming example tool<br />
** Start with opusrtp.c in [https://git.xiph.org/?p=opus-tools.git opus-tools]<br />
** 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<br />
** Make sending similarly generic. Maybe just <code>opusrtp source.opus -o rtp://example.com:5431/</code> to send source.opus out to the destination?<br />
** Make --sniff save one file per<br />
** Implement DTLS-SRTP. See webrtc.<br />
** audio capture/encode, decode/playback?<br />
** Parse and act on sdp for convenience and testing.<br />
<br />
* Replaygain (half done— needs a gain tool)<br />
<br />
== Surround work ==<br />
<br />
* Apply spreading to energy masking<br />
* More conservative energy masking (not just mean difference) and dynalloc<br />
* Allow SILK/hybrid on center channel for voice?<br />
<br />
== Psychoacoustic stuff ==<br />
<br />
* Adaptive width narrowing and forced intensity stereo bands<br />
<br />
== Experiments ==<br />
<br />
* Test exp_analysis and void_my_warranty.patch<br />
<br />
== Optimisations ==<br />
<br />
* Vectorising comb_filter()<br />
* Use 16-bit mul plus shift in denormalise_bands()<br />
* Optimise MDCT somehow<br />
* Merge MIPS optimisations<br />
<br />
== Future work ==<br />
* psymodel based VBR<br />
* Remove copy in inverse MDCT<br />
* Save some float<->int conversions<br />
* Improvements to LP mode CBR (greg has some code)<br />
* Better handling for the case where FEC has a different bandwidth than the current mode<br />
* PLC transitions on unprotected SILK-SILK bandwidth changes?<br />
* Figure out how to use speech/music detection optimally<br />
** find optimal switching time (low energy/tonality)<br />
* Improve variable frame size</div>Rillianhttps://wiki.xiph.org/index.php?title=User_talk:Rillian&diff=14426User talk:Rillian2014-01-27T16:45:53Z<p>Rillian: /* https */ respond to https link question</p>
<hr />
<div><br />
<br />
== Thanks ==<br />
<br />
Thanks for correcting my spelling mistakes. (I cannot get Opera's spell checker working anymore. No idea why.)<br />
<br />
== https ==<br />
<br />
You converted a load of links on [[OggOpusImplementation]] from "http:" to "https:". Why? These all look like public web pages (so would not be restricted to HTTP Secure), and the few I tried worked fine using non-secure HTTP. (If you wish to respond, please do so here.) [[User:Martin.leese|Martin Leese]] 06:59, 24 January 2014 (PST)<br />
<br />
This change was motivated by the decision at the [[https://www.ietf.org/proceedings/88/minutes/minutes-88-iab-techplenary IETF 88 Technical Plenary]] to treat surveillance as an attack and address it in that body's work. Using https links improves reader privacy and therefore is preferable when it is available. This had also become Xiph.Org policy since the draft was initially written.<br />
<br />
You are correct that the linked resources are generally also available over http. Did you have trouble accessing the draft references over https?</div>Rillianhttps://wiki.xiph.org/index.php?title=OggOpusImplementation&diff=14418OggOpusImplementation2014-01-23T21:12:09Z<p>Rillian: /* Rockbox */ 3.13 release date</p>
<hr />
<div>== Implementation Status ==<br />
<br />
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.<br />
<br />
What follows is a brief summary of major implementations of the draft, and their status.<br />
This is intended to help understand the status of each portion of the draft, per [https://tools.ietf.org/html/rfc6982 RFC 6982].<br />
<br />
=== opus-tools ===<br />
<br />
The initial development implementation of this draft was in the opusenc, opusdec, and opusinfo command-line utilties, part of the opus-tools package and repository.<br />
While still 'development' status (pre-1.0) these utilities are in active public use, and have shipped with Linux distributions and homebrew for MacOS.<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://git.xiph.org/?p=opus-tools.git<br />
* http://www.opus-codec.org/downloads/<br />
<br />
=== opusfile ===<br />
<br />
The opusfile library is a separate implementation of this draft as a helper library for demuxing and decoding.<br />
Like opus-tools, it supports metadata, multichannel, start and end trimming, the gain field, live streams, and chained files.<br />
Its primary focus is efficient seeking, including over HTTP(S) and in chained streams.<br />
It currently does not create Ogg Opus files.<br />
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.<br />
<br />
This implementation is open source.<br />
<br />
* https://git.xiph.org/?p=opusfile.git<br />
* http://www.opus-codec.org/downloads/<br />
<br />
=== Firefox ===<br />
<br />
The Firefox web browser is a widely deployed implementation of this draft.<br />
Basic playback support with the HTML5 &lt;audio&gt; element, including start and end trimming, the gain field, live streams, multiplexing with other streams (for, e.g., the &lt;video&gt; tag), and seeking, was added in Firefox 15, in production release starting August 28, 2012.<br />
Multichannel support was added in Firefox 17, in production release starting November 20, 2012.<br />
Metadata support was added in Firefox 18, in production release starting January 8, 2013.<br />
Chained file support (as streams only, with seeking disabled) was added in Firefox 20, in production release starting April 2, 2013.<br />
Encoding support was added in Firefox 26, in production release starting December 10, 2013.<br />
<br />
This implementation is open source.<br />
<br />
* https://mozilla.org/firefox/<br />
* https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=674225<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=748144<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=778050<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=455165<br />
* https://bugzilla.mozilla.org/show_bug.cgi?id=842243<br />
<br />
=== Chrome ===<br />
<br />
Google's Chrome web browser 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.<br />
This implementation currently does not support end trimming, the gain tag, chained files.<br />
Prior to M33 support required passing --enable-opus-playback on the command line when invoking the executable.<br />
<br />
This implementation is based on open source code in Chromium and WebKit.<br />
<br />
* https://www.google.com/intl/en/chrome/browser/<br />
* https://www.google.com/intl/en/chrome/browser/canary.html<br />
* https://code.google.com/p/chromium/issues/detail?id=104241<br />
<br />
=== GStreamer ===<br />
<br />
The GStreamer media framework includes an implementation of this draft.<br />
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, multiplexing with other streams (e.g., video), and seeking.<br />
Support was first added in early 2011, and is part of the 0.11 and 1.0.x releases.<br />
The code implementing this draft is in the gst-plugins-bad collection, which generally indicates unsupported and/or experimental code, despite its release status.<br />
<br />
This implementation is open source.<br />
<br />
* http://gstreamer.net/<br />
* http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/<br />
<br />
=== FFmpeg ===<br />
<br />
The popular media framework and conversion tool FFmpeg implements some of this draft.<br />
End trimming is not implemented, so file durations are not exactly preserved.<br />
<br />
This implementation is open source.<br />
<br />
* https://ffmpeg.org/<br />
<br />
=== libav ===<br />
<br />
The development repository for libav implements this draft, similar to FFmpeg.<br />
<br />
This implementation is open source.<br />
<br />
* https://libav.org/<br />
<br />
=== VLC ===<br />
<br />
VLC is another widely deployed implementation of demuxing, decoding, and playback support for this draft.<br />
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).<br />
Opus support was added in version 2.0.4, released on October 18, 2012.<br />
<br />
This implementation is open source.<br />
<br />
* https://www.videolan.org/vlc/<br />
* https://git.videolan.org/?p=vlc.git<br />
* https://trac.videolan.org/vlc/ticket/7185<br />
<br />
=== foobar2000 ===<br />
<br />
A popular Windows application, foobar2000 implements read, write, and playback support for this draft.<br />
It supports metadata, multichannel, start and end trimming, the gain field, live streams, chained files, and seeking.<br />
Opus support was added in version 1.1.14, released on August 17, 2012.<br />
Encoding support is implemented using opusenc from opus-tools.<br />
<br />
This implementation is closed source.<br />
<br />
* http://www.foobar2000.org/<br />
<br />
=== Rockbox ===<br />
<br />
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.<br />
It supports metadata, start and end trimming, the gain field, and seeking.<br />
It does not currently support multichannel or chained files.<br />
<br />
This implementation is open source.<br />
<br />
* http://www.rockbox.org/<br />
* http://git.rockbox.org/?p=rockbox.git<br />
* http://gerrit.rockbox.org/r/#/c/300/</div>Rillian