<remark><p>Initial published version, split from XEP-0266.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0167; defines the &xep0166; signalling exchanges needed to establish video sessions using the Real-time Transport Protocol &rfc3550;; however, it does not say which video codecs are mandatory-to-implement, since the state of codec technologies is more fluid than the signalling interactions. This document fills that gap by providing guidance to Jingle developers regarding voice and video codecs.</p>
<p>Because codec technologies are typically subject to patents, the topics discussed here are controversial. This document attempts to steer a middle path between (1) specifying mandatory-to-implement technologies that realistically will not be implemented and deployed and (2) providing guidelines that, while realistic, do not encourage the implementation and deployment of patent-clear technologies.</p>
<pclass='box'>This document does not yet provide binding recommendations to the XMPP developer community regarding mandatory-to-implement technologies; however, it provides input that the &XSF; could use in making such recommendations.</p>
<p>The ideal codec would meet the following criteria:</p>
<dl>
<di><dt>Quality</dt><dd>The encoding quality is acceptable for deployment among XMPP users.</dd></di>
<di><dt>Packetization</dt><dd>The specification of the codec clearly defines packetization of data for sending over RTP.</dd></di>
<di><dt>Availability</dt><dd>The codec can be implemented on a wide variety of computing platforms and is commonly used in Internet or other systems.</dd></di>
<di><dt>Patents</dt><dd>The codec is patent-clear. <note>The term patent-clear does not necessarily mean that no patents have ever been applied for or granted regarding a technology, or that the technology is completely free from patents (since such a judgment is nearly impossible to make, and is outside the purview of the XMPP developer community and the XMPP Standards Foundation); the term means only that those who implement the technology are generally understood to be relatively safe from the threat of patent litigation, either because any relevant patents have expired, were filed in a defensive manner, or are made available under suitable royalty-free licenses.</note> (Although most XMPP developers would prefer to implement codecs that are patent-clear, such options are not always widely implemented and deployed.)</dd></di>
</dl>
<p>Unfortunately, not all codecs meet those criteria. In the remainder of this document we discuss the video codecs that are most appropriate for implementation in Jingle RTP applications.</p>
</section1>
<section1topic='Codecs'anchor='codecs'>
<section2topic='Dirac'anchor='codecs-dirac'>
<p>Dirac is a general-purpose video compression technology developed by the BBC that has been licensed in the open. It is used for everything from Internet streaming to HDTV. To date there is no RTP packetization deveintion for Dirac; however, such a format is under development.</p>
<tablecaption='Codec Considerations for Dirac'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>High quality.</td>
<td>Not yet defined.</td>
<td>Freely downloadable under both GPL and LGPL at <<linkurl='http://diracvideo.org/'>http://diracvideo.org/</link>>; commonly deployed but not yet in video over IP systems because of the lack of an RTP packetization format.</td>
<td>Diract is patent-clear, and the BBC has allowed its related patents to lapse.</td>
</tr>
</table>
</section2>
<section2topic='H.264'anchor='codecs-h264'>
<p>H.264 is a technology for video compression jointly designed by the ITU and the &ISO;. The following table summarizes the available information about H.264.</p>
<tablecaption='Codec Considerations for H.264'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>High quality.</td>
<td>See &rfc3984;.</td>
<td>Commonly deployed in commercial video systems. Not freely downloadable; both software implementations and service deployments can be subject to royalty payments for commercial use.</td>
<td>Patented.</td>
</tr>
</table>
</section2>
<section2topic='Theora'anchor='codecs-theora'>
<p>According to the theora.org website, the Theora codec is "a free and open video compression format". Theora is based on the VP3 codec originally developed by On2 Technologies and is now maintained by the <linkurl='http://www.xiph.org/'>Xiph.org Foundation</link>. The following table summarizes the available information about Theora.</p>
<tablecaption='Codec Considerations for Theora'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>Acceptable quality.</td>
<td>See &rtptheora;.</td>
<td>Freely downloadable under BSD license at <<linkurl='http://theora.org/'>http://theora.org/</link>>; not yet commonly deployed, especially on devices that have deployed H.264 instead.</td>
<td>On2's patents over VP3 were contributed to the Xiph.org Foundation in 2001.</td>
</tr>
</table>
</section2>
<section2topic='VP8'anchor='codecs-vp8'>
<p>VP8 is an open video compression format originally developed (as was Theora) by On2 Technologies and released by Google after it acquired On2 Technologies in 2010. The following table summarizes the available information about Theora.</p>
<tablecaption='Codec Considerations for VP8'>
<tr>
<th>Quality</th>
<th>Packetization</th>
<th>Availability</th>
<th>Patents</th>
</tr>
<tr>
<td>High quality.</td>
<td>See &rtpvp8;.</td>
<td>Freely downloadable under BSD-like license at <<linkurl='http://webmproject.org/'>http://webmproject.org/</link>>; not yet commonly deployed, especially on devices that have deployed H.264 instead.</td>
<td>Google released the VP8 bitstream format under an irrevocable free patent license in 2010.</td>
</tr>
</table>
</section2>
</section1>
<section1topic='Guidance for Implementers'anchor='impl'>
<p>The situation regarding video codecs is more murky, and implementers face difficult tradeoffs. Although Theora is patent-clear and freely implementable, it is not yet commonly deployed. Although Dirac is patent-clear and deployed fairly widely, no RTP packetization format has been defined for it. Although deployment of H.264 is fairly common, it is not patent-clear or freely implementable. For many open-source / free software projects and smaller technology vendors, implementation of H.264 is either impossible (because of patents and licensing restrictions) or prohibitively expensive (because of royalty payments). These developers are strongly encouraged to implement Theora or Dirac and also to urge wider adoption of Theora and Dirac among larger technology vendors. However, this document acknowledges that it may take some time before Theora and Dirac are commonly deployed (especially on mobile devices) and that systems based on H.264 might be dominant in the marketplace for several years. This situation is unfortunate but cannot be directly changed by the XMPP developer community.</p>
<p>Because video codecs are not as mature as audio codecs, it is not yet possible for the XSF to recommend a mandatory-to-implement technology for Jingle video. However, in the future it might be possible to recommend one of the codecs described in this document.</p>
<p>For security considerations related to Jingle RTP sessions, refer to <cite>XEP-0167</cite>. This document introduces no new security considerations. See also the security considerations described in the relevant codec specifications.</p>
<p>This document requires no interaction with the ®ISTRAR;.</p>
</section1>
<section1topic='Acknowledgements'anchor='ack'>
<p>Thanks to Olivier Crête, Dave Cridland, Florian Jensen, Justin Karneges, Evgeniy Khramtsov, Marcus Lundblad, Tobias Markmann, Pedro Melo, Jack Moffitt, Jeff Muller, Jehan Pagès, Arc Riley, Kevin Smith, Remko Tronçon, Justin Uberti, and Paul Witty for their feedback.</p>
