Mirror of roytam1's UXP fork just in case Moonchild and Tobin decide to go after him
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

57 lines
3.2 KiB

/*! \page usage_decode Decoding
The aom_codec_decode() function is at the core of the decode loop. It
processes packets of compressed data passed by the application, producing
decoded images. The decoder expects packets to comprise exactly one image
frame of data. Packets \ref MUST be passed in decode order. If the
application wishes to associate some data with the frame, the
<code>user_priv</code> member may be set.
\ref samples
\section usage_cb Callback Based Decoding
There are two methods for the application to access decoded frame data. Some
codecs support asynchronous (callback-based) decoding \ref usage_features
that allow the application to register a callback to be invoked by the
decoder when decoded data becomes available. Decoders are not required to
support this feature, however. Like all \ref usage_features, support can be
determined by calling aom_codec_get_caps(). Callbacks are available in both
frame-based and slice-based variants. Frame based callbacks conform to the
signature of #aom_codec_put_frame_cb_fn_t and are invoked once the entire
frame has been decoded. Slice based callbacks conform to the signature of
#aom_codec_put_slice_cb_fn_t and are invoked after a subsection of the frame
is decoded. For example, a slice callback could be issued for each
macroblock row. However, the number and size of slices to return is
implementation specific. Also, the image data passed in a slice callback is
not necessarily in the same memory segment as the data will be when it is
assembled into a full frame. For this reason, the application \ref MUST
examine the rectangles that describe what data is valid to access and what
data has been updated in this call. For all their additional complexity,
slice based decoding callbacks provide substantial speed gains to the
overall application in some cases, due to improved cache behavior.
\section usage_frame_iter Frame Iterator Based Decoding
If the codec does not support callback based decoding, or the application
chooses not to make use of that feature, decoded frames are made available
through the aom_codec_get_frame() iterator. The application initializes the
iterator storage (of type #aom_codec_iter_t) to NULL, then calls
aom_codec_get_frame repeatedly until it returns NULL, indicating that all
images have been returned. This process may result in zero, one, or many
frames that are ready for display, depending on the codec.
\section usage_postproc Postprocessing
Postprocessing is a process that is applied after a frame is decoded to
enhance the image's appearance by removing artifacts introduced in the
compression process. It is not required to properly decode the frame, and
is generally done only when there is enough spare CPU time to execute
the required filters. Codecs may support a number of different
postprocessing filters, and the available filters may differ from platform
to platform. Embedded devices often do not have enough CPU to implement
postprocessing in software. The filter selection is generally handled
automatically by the codec.
*/