usage_dx.dox

   1 /*! \page usage_decode Decoding
   2
   3     The vpx_codec_decode() function is at the core of the decode loop. It
   4     processes packets of compressed data passed by the application, producing
   5     decoded images. The decoder expects packets to comprise exactly one image
   6     frame of data. Packets \ref MUST be passed in decode order. If the
   7     application wishes to associate some data with the frame, the
   8     <code>user_priv</code> member may be set. The <code>deadline</code>
   9     parameter controls the amount of time in microseconds the decoder should
  10     spend working on the frame. This is typically used to support adaptive
  11     \ref usage_postproc based on the amount of free CPU time. For more
  12     information on the <code>deadline</code> parameter, see \ref usage_deadline.
  13
  14     \if samples
  15     \ref samples
  16     \endif
  17
  18
  19     \section usage_cb Callback Based Decoding
  20     There are two methods for the application to access decoded frame data. Some
  21     codecs support asynchronous (callback-based) decoding \ref usage_features
  22     that allow the application to register a callback to be invoked by the
  23     decoder when decoded data becomes available. Decoders are not required to
  24     support this feature, however. Like all \ref usage_features, support can be
  25     determined by calling vpx_codec_get_caps(). Callbacks are available in both
  26     frame-based and slice-based variants. Frame based callbacks conform to the
  27     signature of #vpx_codec_put_frame_cb_fn_t and are invoked once the entire
  28     frame has been decoded. Slice based callbacks conform to the signature of
  29     #vpx_codec_put_slice_cb_fn_t and are invoked after a subsection of the frame
  30     is decoded. For example, a slice callback could be issued for each
  31     macroblock row. However, the number and size of slices to return is
  32     implementation specific. Also, the image data passed in a slice callback is
  33     not necessarily in the same memory segment as the data will be when it is
  34     assembled into a full frame. For this reason, the application \ref MUST
  35     examine the rectangles that describe what data is valid to access and what
  36     data has been updated in this call. For all their additional complexity,
  37     slice based decoding callbacks provide substantial speed gains to the
  38     overall application in some cases, due to improved cache behavior.
  39
  40
  41     \section usage_frame_iter Frame Iterator Based Decoding
  42     If the codec does not support callback based decoding, or the application
  43     chooses not to make use of that feature, decoded frames are made available
  44     through the vpx_codec_get_frame() iterator. The application initializes the
  45     iterator storage (of type #vpx_codec_iter_t) to NULL, then calls
  46     vpx_codec_get_frame repeatedly until it returns NULL, indicating that all
  47     images have been returned. This process may result in zero, one, or many
  48     frames that are ready for display, depending on the codec.
  49
  50
  51     \section usage_postproc Postprocessing
  52     Postprocessing is a process that is applied after a frame is decoded to
  53     enhance the image's appearance by removing artifacts introduced in the
  54     compression process. It is not required to properly decode the frame, and
  55     is generally done only when there is enough spare CPU time to execute
  56     the required filters. Codecs may support a number of different
  57     postprocessing filters, and the available filters may differ from platform
  58     to platform. Embedded devices often do not have enough CPU to implement
  59     postprocessing in software. The filter selection is generally handled
  60     automatically by the codec, depending on the amount of time remaining before
  61     hitting the user-specified \ref usage_deadline after decoding the frame.
  62
  63
  64 */