video-interface.tex

   1 This section defines the video formats supported by this specification.
   2
   3 A selection of widely used video formats are defined in normative Annex
   4 \ref{videoformatdefaults}. These video formats are characterized by
   5 their widespread use in television, cinema and multimedia applications.
   6
   7 This list is not exhaustive, however, and Dirac is a general purpose video
   8 compression system. These predefined formats are base formats that
   9 may be modified element by
  10 element to support a much larger range of possible video formats. Support
  11 is provided by the sequence parameters of the bitstream (Section
  12 \ref{sequenceheader}) for signalling both the base video format and
  13 any modifications for complete characterization of the video format metadata.
  14
  15
  16 \subsection{Colour model}
  17
  18 Dirac supports any video format that codes the raw image colors in a luma
  19 (grey-level) component with two associated chroma (color difference) components.
  20  These components are referred to as $Y$, $C1$ and $C2$.
  21
  22 In ITU defined systems (including ITU-BT.709, ITU-R BT.1361 and ITU-BT.1700),
  23 the $Y$, $C1$ and $C2$ values shall relate to the $E’_Y$, $E’_U$ and $E’_V$
  24 video components respectively. These video components are also widely referred
  25 to as $Y, U, V$ and $Y, C_B , C_R$.
  26
  27 In the ITU-T H.264 reversible color transform, the $Y$, $C1$ and $C2$ values
  28 shall correspond to the video components $Y, C_O, C_G$.
  29
  30 \begin{informative}
  31 Coding using $Y, C_O, C_G$ provides a simple reversible conversion to and from
  32 RGB components by using lossless integer transforms. The use of $Y, C_O, C_G$
  33 supports lossless coding of RGB video and allows Dirac to be treated as an RGB
  34 compression system for applications that require this feature.
  35 \end{informative}
  36
  37 \subsection{Interlace}
  38
  39 Dirac supports both interlace and progressive formats. Interlace formats may be
  40  either top field first or bottom field first.
  41
  42 Dirac codes pictures where a picture may be a frame or a field. Fields consist
  43 of sets of alternate lines of video frames (even and odd lines). A pair of
  44 fields constituting a frame may correspond to distinct time intervals (true
  45 interlace scanning) or to the same time interval (progressive segmented frames).
  46  Hence the configuration of frame/field coding is independent of whether the
  47 video format is interlaced or progressive.
  48
  49 \subsection{Component sampling}
  50
  51 Chroma components $C1$ and $C2$ may be coded with the same dimensions as the Y
  52  component (4:4:4) sampling, or with half-width (4:2:2) or half-dimension
  53 (4:2:0) sampling.
  54
  55 $Y$, $C1$ and $C2$ picture components shall be sampled at the same temporal
  56 instant.
  57
  58 \begin{informative}
  59 All pictures are considered as individual entities whether or not all lines were
  60  sampled at the same instant. In video sequences that are not frame-based, such
  61 as 30fps interlaced video carrying 24fps progressive images in a 3:2
  62 pull-down sequence, the compression performance may not be optimum. In such
  63 cases, a pre-processor may provide an encoder with a more easily compressed
  64 source such as the original 24fps source pictures. Such pre-processing does not form any part of this specification.
  65 \end{informative}
  66
  67 \subsection{Bit resolution}
  68
  69 The bit depth of each component sample is, in principle, unrestricted.
  70 Application-specific codecs may restrict the supported bit depth to a single
  71 value or a limited range of values.
  72
  73 Video is represented internally within the decoder specification as a bipolar
  74  (signed integer) signal. Video is presented at the video interface as an
  75 unsigned integer value by addition of an offset to these values
  76 (Section \ref{videooutput}). Metadata concerning black level and white level
  77 is transmitted
  78  within the data stream (Section \ref{signalrange}), but is not enforced at the
  79 decoder video interface: output video may undershoot or overshoot these values.
  80
  81 \subsection{Picture frame size and rate}
  82
  83 The frame size and frame rate is, in principle, unrestricted.
  84 Application-specific codecs may restrict the supported frame size and frame rate
  85  to a single value or a limited range of values, and compliance to a given level
  86  implies constraints on the values as specified in Annex \ref{profilelevel}.
  87