coder-intro.tex

   1 It is not our intention to be prescriptive about how coders should or
   2 should not be organised. Any coder which produces a compliant bytestream
   3 may have a place in someone's work. This Appendix is provided to show
   4 that there are quite a lot of things to consider.
   5
   6 First of all, it is worth noting the competing factors of quality, bit
   7 rate, complexity and delay.
   8
   9 High quality usually requires a high bit rate. To maintain a consistent
  10 quality may require the bit rate to be variable. This leads to a
  11 potential need for a fair amount of buffer storage in a system which
  12 provides a fixed bit rate.
  13
  14 Any system which provides a lot of compression (i.e. a low bit rate)
  15 requires full use of all the tools. When we explore the capacity used by
  16 each element, we find that the Intra frames tend to require most
  17 capacity. Access Units with many Inter frames and few Intra frames will
  18 therefore seem to be a desirable solution - except for the fact that
  19 this will potentially increase the necessary buffer size and lengthen
  20 the time between access points.
  21
  22 Of the data provided in each frame, the data used for motion vectors and
  23 prediction is roughly the same as the quantity of data used for the
  24 wavelet coefficients. The trade off between the two can be enhanced by
  25 careful rate distortion optimisation.
  26
  27 In some low-complexity implementations, it is possible to simplify the
  28 motion vectors, or even omit them.
  29
  30 For low delay systems, a sequence of Intra frames gives the best
  31 performance.
  32