/usr/share/doc/libvpx-doc/html/usage.html is in libvpx-doc 1.7.0-3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.13"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>WebM Codec SDK: Usage</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td id="projectalign" style="padding-left: 0.5em;">
<div id="projectname">WebM Codec SDK
</div>
</td>
</tr>
</tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.13 -->
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
$(function() {
initMenu('',false,false,'search.php','Search');
});
</script>
<div id="main-nav"></div>
</div><!-- top -->
<div class="header">
<div class="headertitle">
<div class="title">Usage </div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><p>The vpx multi-format codec SDK provides a unified interface amongst its supported codecs. This abstraction allows applications using this SDK to easily support multiple video formats with minimal code duplication or "special casing." This section describes the interface common to all codecs. For codec-specific details, see the <a class="el" href="group__codecs.html">Supported Codecs</a> page.</p>
<p>The following sections are common to all codecs:</p><ul>
<li><a class="el" href="usage.html#usage_types">Important Data Types</a></li>
<li><a class="el" href="usage.html#usage_features">Features</a></li>
<li><a class="el" href="usage.html#usage_init">Initialization</a></li>
<li><a class="el" href="usage.html#usage_errors">Error Handling</a></li>
</ul>
<p>For more information on decoder and encoder specific usage, see the following pages: </p><ul>
<li><a class="el" href="usage_decode.html">Decoding</a> </li>
<li><a class="el" href="usage_encode.html">Encoding</a></li>
</ul>
<h1><a class="anchor" id="usage_types"></a>
Important Data Types</h1>
<p>There are two important data structures to consider in this interface.</p>
<h2><a class="anchor" id="usage_ctxs"></a>
Contexts</h2>
<p>A context is a storage area allocated by the calling application that the codec may write into to store details about a single instance of that codec. Most of the context is implementation specific, and thus opaque to the application. The context structure as seen by the application is of fixed size, and thus can be allocated with automatic storage or dynamically on the heap.</p>
<p>Most operations require an initialized codec context. Codec context instances are codec specific. That is, the codec to be used for the encoded video must be known at initialization time. See <a class="el" href="group__codec.html#gad03e2dfa6ae511db7d25be6bbb336233" title="Codec context structure. ">vpx_codec_ctx_t</a> for further information.</p>
<h2><a class="anchor" id="usage_ifaces"></a>
Interfaces</h2>
<p>A codec interface is an opaque structure that controls how function calls into the generic interface are dispatched to their codec-specific implementations. Applications <a class="el" href="rfc2119.html#MUSTNOT">MUST NOT</a> attempt to examine or override this storage, as it contains internal implementation details likely to change from release to release.</p>
<p>Each supported codec will expose an interface structure to the application as an <code>extern</code> reference to a structure of the incomplete type <a class="el" href="group__codec.html#gae99c3b04f4a567a311211cce3ae6b83b" title="Codec interface structure. ">vpx_codec_iface_t</a>.</p>
<h1><a class="anchor" id="usage_features"></a>
Features</h1>
<p>Several "features" are defined that are optionally implemented by codec algorithms. Indeed, the same algorithm may support different features on different platforms. The purpose of defining these features is that when they are implemented, they conform to a common interface. The features, or capabilities, of an algorithm can be queried from it's interface by using the <a class="el" href="group__codec.html#ga43adff58759093401235fb99247c82b8" title="Get the capabilities of an algorithm. ">vpx_codec_get_caps()</a> method. Attempts to invoke features not supported by an algorithm will generally result in <a class="el" href="group__codec.html#ggada1084710837ad363b92f2379dd2b8d2a4470784ba5a3ef84dc0697d5489dd292" title="Algorithm does not have required capability. ">VPX_CODEC_INCAPABLE</a>.</p>
<p>Currently defined decoder features include:</p><ul>
<li><a class="el" href="usage_decode.html#usage_cb">Callback Based Decoding</a></li>
<li><a class="el" href="usage_decode.html#usage_postproc">Postprocessing</a></li>
</ul>
<h1><a class="anchor" id="usage_init"></a>
Initialization</h1>
<p>To initialize a codec instance, the address of the codec context and interface structures are passed to an initialization function. Depending on the <a class="el" href="usage.html#usage_features">Features</a> that the codec supports, the codec could be initialized in different modes.</p>
<p>To prevent cases of confusion where the ABI of the library changes, the ABI is versioned. The ABI version number must be passed at initialization time to ensure the application is using a header file that matches the library. The current ABI version number is stored in the preprocessor macros <a class="el" href="group__codec.html#gaf7e9cad2df0f81679b881f46740ad097" title="Current ABI version number. ">VPX_CODEC_ABI_VERSION</a>, <a class="el" href="group__encoder.html#gaa4f0b52293c08ba672429c3a03648b9d" title="Current ABI version number. ">VPX_ENCODER_ABI_VERSION</a>, and <a class="el" href="group__decoder.html#ga462b459e7ae13937e1eae1776245db12" title="Current ABI version number. ">VPX_DECODER_ABI_VERSION</a>. For convenience, each initialization function has a wrapper macro that inserts the correct version number. These macros are named like the initialization methods, but without the _ver suffix.</p>
<p>The available initialization methods are: </p><ul>
<li><a class="el" href="group__encoder.html#ga3d490a2a9a6acd7c9ef82a603155f3cf" title="Convenience macro for vpx_codec_enc_init_ver() ">vpx_codec_enc_init</a> (calls <a class="el" href="group__encoder.html#ga1472ec347010fe5ef32766a299e57cc4" title="Initialize an encoder instance. ">vpx_codec_enc_init_ver()</a>) </li>
<li><a class="el" href="group__encoder.html#gad7ae1d930cf110d6fe70beafeacfd9c7" title="Convenience macro for vpx_codec_enc_init_multi_ver() ">vpx_codec_enc_init_multi</a> (calls <a class="el" href="group__encoder.html#ga1c0415984a5469687f53613a5471f53d" title="Initialize multi-encoder instance. ">vpx_codec_enc_init_multi_ver()</a>) </li>
<li><a class="el" href="group__decoder.html#ga8c2f0b12f1bd4927eb3c68b01eab19d3" title="Convenience macro for vpx_codec_dec_init_ver() ">vpx_codec_dec_init</a> (calls <a class="el" href="group__decoder.html#ga6435c3e8cb9408f1c0c3d052a3a577b7" title="Initialize a decoder instance. ">vpx_codec_dec_init_ver()</a>)</li>
</ul>
<h1><a class="anchor" id="usage_errors"></a>
Error Handling</h1>
<p>Almost all codec functions return an error status of type <a class="el" href="group__codec.html#gada1084710837ad363b92f2379dd2b8d2" title="Algorithm return codes. ">vpx_codec_err_t</a>. The semantics of how each error condition should be processed is clearly defined in the definitions of each enumerated value. Error values can be converted into ASCII strings with the <a class="el" href="group__codec.html#ga4d265df00d42b36a4f0e3eb83fc22c5e" title="Retrieve error synopsis for codec context. ">vpx_codec_error()</a> and <a class="el" href="group__codec.html#gaaddf5c1f609ef18c7c8800d102fcefa6" title="Convert error number to printable string. ">vpx_codec_err_to_string()</a> methods. The difference between these two methods is that <a class="el" href="group__codec.html#ga4d265df00d42b36a4f0e3eb83fc22c5e" title="Retrieve error synopsis for codec context. ">vpx_codec_error()</a> returns the error state from an initialized context, whereas <a class="el" href="group__codec.html#gaaddf5c1f609ef18c7c8800d102fcefa6" title="Convert error number to printable string. ">vpx_codec_err_to_string()</a> can be used in cases where an error occurs outside any context. The enumerated value returned from the last call can be retrieved from the <code>err</code> member of the decoder context as well. Finally, more detailed error information may be able to be obtained by using the <a class="el" href="group__codec.html#ga29273cb552ed1a437fe263c4a0a54300" title="Retrieve detailed error information for codec context. ">vpx_codec_error_detail()</a> method. Not all errors produce detailed error information.</p>
<p>In addition to error information, the codec library's build configuration is available at runtime on some platforms. This information can be returned by calling <a class="el" href="group__codec.html#ga20922bad85472e76d5f61c21cb423af7" title="Return the build configuration. ">vpx_codec_build_config()</a>, and is formatted as a base64 coded string (comprised of characters in the set [a-z_a-Z0-9+/]). This information is not useful to an application at runtime, but may be of use to vpx for support.</p>
<h1><a class="anchor" id="usage_deadline"></a>
Deadline</h1>
<p>Both the encoding and decoding functions have a <code>deadline</code> parameter. This parameter indicates the amount of time, in microseconds (us), that the application wants the codec to spend processing before returning. This is a soft deadline – that is, the semantics of the requested operation take precedence over meeting the deadline. If, for example, an application sets a <code>deadline</code> of 1000us, and the frame takes 2000us to decode, the call to <a class="el" href="group__decoder.html#ga3441e157a7a69108bca9a069f2ee8e0d" title="Decode data. ">vpx_codec_decode()</a> will return after 2000us. In this case the deadline is not met, but the semantics of the function are preserved. If, for the same frame, an application instead sets a <code>deadline</code> of 5000us, the decoder will see that it has 3000us remaining in its time slice when decoding completes. It could then choose to run a set of <a class="el" href="usage_decode.html#usage_postproc">Postprocessing</a> filters, and perhaps would return after 4000us (instead of the allocated 5000us). In this case the deadline is met, and the semantics of the call are preserved, as before.</p>
<p>The special value <code>0</code> is reserved to represent an infinite deadline. In this case, the codec will perform as much processing as possible to yield the highest quality frame.</p>
<p>By convention, the value <code>1</code> is used to mean "return as fast as
possible." </p>
</div></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by  <a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.13
</small></address>
</body>
</html>
|