usage.dox 11 KB
 John Koleszar committed May 18, 2010 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 /*!\page usage Usage 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 \ref codecs page. The following sections are common to all codecs: - \ref usage_types - \ref usage_features - \ref usage_init - \ref usage_errors Fore more information on decoder and encoder specific usage, see the following pages: \if decoder - \subpage usage_decode \endif \if decoder - \subpage usage_encode \endif \section usage_types Important Data Types There are two important data structures to consider in this interface. \subsection usage_ctxs Contexts 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  James Zern committed Feb 16, 2011 28  size, and thus can be allocated with automatic storage or dynamically  John Koleszar committed May 18, 2010 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  on the heap. 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 #vpx_codec_ctx_t for further information. \subsection usage_ifaces Interfaces A codec interface is an opaque structure that controls how function calls into the generic interface are dispatched to their codec-specific implementations. Applications \ref MUSTNOT attempt to examine or override this storage, as it contains internal implementation details likely to change from release to release. Each supported codec will expose an interface structure to the application as an extern reference to a structure of the incomplete type #vpx_codec_iface_t. \section usage_features Features 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 vpx_codec_get_caps() method. Attempts to invoke features not supported by an algorithm will generally result in #VPX_CODEC_INCAPABLE. Currently defined features available in both encoders and decoders include: - \subpage usage_xma \if decoder Currently defined decoder features include: - \ref usage_cb - \ref usage_postproc \endif \section usage_init Initialization To initialize a codec instance, the address of the codec context and interface structures are passed to an initialization function. Depending on the \ref usage_features that the codec supports, the codec could be initialized in different modes. Most notably, the application may choose to use \ref usage_xma mode to gain fine grained control over how and where memory is allocated for the codec. 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  James Zern committed Feb 16, 2011 77  preprocessor macros #VPX_CODEC_ABI_VERSION, #VPX_ENCODER_ABI_VERSION, and  John Koleszar committed May 18, 2010 78 79 80 81 82 83 84  #VPX_DECODER_ABI_VERSION. 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. The available initialization methods are: \if encoder - #vpx_codec_enc_init (calls vpx_codec_enc_init_ver()) \endif  Yunqing Wang committed Dec 05, 2011 85  \if multi-encoder - #vpx_codec_enc_init_multi (calls vpx_codec_enc_init_multi_ver()) \endif  John Koleszar committed May 18, 2010 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128  \if decoder - #vpx_codec_dec_init (calls vpx_codec_dec_init_ver()) \endif \section usage_errors Error Handling Almost all codec functions return an error status of type #vpx_codec_err_t. 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 vpx_codec_error() and vpx_codec_err_to_string() methods. The difference between these two methods is that vpx_codec_error() returns the error state from an initialized context, whereas vpx_codec_err_to_string() 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 err member of the decoder context as well. Finally, more detailed error information may be able to be obtained by using the vpx_codec_error_detail() method. Not all errors produce detailed error information. 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 vpx_codec_build_config(), 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. \section usage_deadline Deadline Both the encoding and decoding functions have a deadline 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 deadline of 1000us, and the frame takes 2000us to decode, the call to vpx_codec_decode() 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 deadline 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 \ref usage_postproc 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. The special value 0 is reserved to represent an infinite deadline. In this case, the codec will perform as much processing as  James Zern committed Feb 16, 2011 129  possible to yield the highest quality frame.  John Koleszar committed May 18, 2010 130 131 132 133 134 135 136 137 138  By convention, the value 1 is used to mean "return as fast as possible." */ /*! \page usage_xma External Memory Allocation Applications that wish to have fine grained control over how and where  James Zern committed Feb 16, 2011 139  decoders allocate memory \ref MAY make use of the eXternal Memory Allocation  John Koleszar committed May 18, 2010 140 141 142 143 144 145 146  (XMA) interface. Not all codecs support the XMA \ref usage_features. To use a decoder in XMA mode, the decoder \ref MUST be initialized with the vpx_codec_xma_init_ver() function. The amount of memory a decoder needs to allocate is heavily dependent on the size of the encoded video frames. The size of the video must be known before requesting the decoder's memory map. This stream information can be obtained with the vpx_codec_peek_stream_info()  James Zern committed Feb 16, 2011 147  function, which does not require a constructed decoder context. If the exact  John Koleszar committed May 18, 2010 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178  stream is not known, a stream info structure can be created that reflects the maximum size that the decoder instance is required to support. Once the decoder instance has been initialized and the stream information determined, the application calls the vpx_codec_get_mem_map() iterator repeatedly to get a list of the memory segments requested by the decoder. The iterator value should be initialized to NULL to request the first element, and the function will return #VPX_CODEC_LIST_END to signal the end of the list. After each segment is identified, it must be passed to the codec through the vpx_codec_set_mem_map() function. Segments \ref MUST be passed in the same order as they are returned from vpx_codec_get_mem_map(), but there is no requirement that vpx_codec_get_mem_map() must finish iterating before vpx_codec_set_mem_map() is called. For instance, some applications may choose to get a list of all requests, construct an optimal heap, and then set all maps at once with one call. Other applications may set one map at a time, allocating it immediately after it is returned from vpx_codec_get_mem_map(). After all segments have been set using vpx_codec_set_mem_map(), the codec may be used as it would be in normal internal allocation mode. \section usage_xma_seg_id Segment Identifiers Each requested segment is identified by an identifier unique to that decoder type. Some of these identifiers are private, while others are enumerated for application use. Identifiers not enumerated publicly are subject to change. Identifiers are non-consecutive. \section usage_xma_seg_szalign Segment Size and Alignment The sz (size) and align (alignment) parameters describe the required size and alignment of the requested segment. Alignment will always be a power of  James Zern committed Feb 16, 2011 179  two. Applications \ref MUST honor the alignment requested. Failure to do so  John Koleszar committed May 18, 2010 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204  could result in program crashes or may incur a speed penalty. \section usage_xma_seg_flags Segment Flags The flags member of the segment structure indicates any requirements or desires of the codec for the particular segment. The #VPX_CODEC_MEM_ZERO flag indicates that the segment \ref MUST be zeroed by the application prior to passing it to the application. The #VPX_CODEC_MEM_WRONLY flag indicates that the segment will only be written into by the decoder, not read. If this flag is not set, the application \ref MUST insure that the memory segment is readable. On some platforms, framebuffer memory is writable but not readable, for example. The #VPX_CODEC_MEM_FAST flag indicates that the segment will be frequently accessed, and that it should be placed into fast memory, if any is available. The application \ref MAY choose to place other segments in fast memory as well, but the most critical segments will be identified by this flag. \section usage_xma_seg_basedtor Segment Base Address and Destructor For each requested memory segment, the application must determine the address of a memory segment that meets the requirements of the codec. This address is set in the base member of the #vpx_codec_mmap structure. If the application requires processing when the segment is no longer used by the codec (for instance to deallocate it or close an associated file descriptor) the dtor and priv members can be set. */