field-order.rst 7.2 KB
Newer Older
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 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
.. -*- coding: utf-8; mode: rst -*-

.. _field-order:

***********
Field Order
***********

We have to distinguish between progressive and interlaced video.
Progressive video transmits all lines of a video image sequentially.
Interlaced video divides an image into two fields, containing only the
odd and even lines of the image, respectively. Alternating the so called
odd and even field are transmitted, and due to a small delay between
fields a cathode ray TV displays the lines interleaved, yielding the
original frame. This curious technique was invented because at refresh
rates similar to film the image would fade out too quickly. Transmitting
fields reduces the flicker without the necessity of doubling the frame
rate and with it the bandwidth required for each channel.

It is important to understand a video camera does not expose one frame
at a time, merely transmitting the frames separated into fields. The
fields are in fact captured at two different instances in time. An
object on screen may well move between one field and the next. For
applications analysing motion it is of paramount importance to recognize
which field of a frame is older, the *temporal order*.

When the driver provides or accepts images field by field rather than
interleaved, it is also important applications understand how the fields
combine to frames. We distinguish between top (aka odd) and bottom (aka
even) fields, the *spatial order*: The first line of the top field is
the first line of an interlaced frame, the first line of the bottom
field is the second line of that frame.

However because fields were captured one after the other, arguing
whether a frame commences with the top or bottom field is pointless. Any
two successive top and bottom, or bottom and top fields yield a valid
frame. Only when the source was progressive to begin with, e. g. when
transferring film to video, two fields may come from the same frame,
creating a natural order.

Counter to intuition the top field is not necessarily the older field.
Whether the older field contains the top or bottom lines is a convention
determined by the video standard. Hence the distinction between temporal
and spatial order of fields. The diagrams below should make this
clearer.

All video capture and output devices must report the current field
order. Some drivers may permit the selection of a different order, to
this end applications initialize the ``field`` field of struct
:ref:`v4l2_pix_format <v4l2-pix-format>` before calling the
51
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. If this is not desired it
52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75
should have the value ``V4L2_FIELD_ANY`` (0).


.. _v4l2-field:

.. flat-table:: enum v4l2_field
    :header-rows:  0
    :stub-columns: 0
    :widths:       3 1 4


    -  .. row 1

       -  ``V4L2_FIELD_ANY``

       -  0

       -  Applications request this field order when any one of the
          ``V4L2_FIELD_NONE``, ``V4L2_FIELD_TOP``, ``V4L2_FIELD_BOTTOM``, or
          ``V4L2_FIELD_INTERLACED`` formats is acceptable. Drivers choose
          depending on hardware capabilities or e. g. the requested image
          size, and return the actual field order. Drivers must never return
          ``V4L2_FIELD_ANY``. If multiple field orders are possible the
          driver must choose one of the possible field orders during
76 77
          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
          :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`. struct
78 79 80 81 82 83 84 85 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 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 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 179 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 205 206 207 208 209 210
          :ref:`v4l2_buffer <v4l2-buffer>` ``field`` can never be
          ``V4L2_FIELD_ANY``.

    -  .. row 2

       -  ``V4L2_FIELD_NONE``

       -  1

       -  Images are in progressive format, not interlaced. The driver may
          also indicate this order when it cannot distinguish between
          ``V4L2_FIELD_TOP`` and ``V4L2_FIELD_BOTTOM``.

    -  .. row 3

       -  ``V4L2_FIELD_TOP``

       -  2

       -  Images consist of the top (aka odd) field only.

    -  .. row 4

       -  ``V4L2_FIELD_BOTTOM``

       -  3

       -  Images consist of the bottom (aka even) field only. Applications
          may wish to prevent a device from capturing interlaced images
          because they will have "comb" or "feathering" artefacts around
          moving objects.

    -  .. row 5

       -  ``V4L2_FIELD_INTERLACED``

       -  4

       -  Images contain both fields, interleaved line by line. The temporal
          order of the fields (whether the top or bottom field is first
          transmitted) depends on the current video standard. M/NTSC
          transmits the bottom field first, all other standards the top
          field first.

    -  .. row 6

       -  ``V4L2_FIELD_SEQ_TB``

       -  5

       -  Images contain both fields, the top field lines are stored first
          in memory, immediately followed by the bottom field lines. Fields
          are always stored in temporal order, the older one first in
          memory. Image sizes refer to the frame, not fields.

    -  .. row 7

       -  ``V4L2_FIELD_SEQ_BT``

       -  6

       -  Images contain both fields, the bottom field lines are stored
          first in memory, immediately followed by the top field lines.
          Fields are always stored in temporal order, the older one first in
          memory. Image sizes refer to the frame, not fields.

    -  .. row 8

       -  ``V4L2_FIELD_ALTERNATE``

       -  7

       -  The two fields of a frame are passed in separate buffers, in
          temporal order, i. e. the older one first. To indicate the field
          parity (whether the current field is a top or bottom field) the
          driver or application, depending on data direction, must set
          struct :ref:`v4l2_buffer <v4l2-buffer>` ``field`` to
          ``V4L2_FIELD_TOP`` or ``V4L2_FIELD_BOTTOM``. Any two successive
          fields pair to build a frame. If fields are successive, without
          any dropped fields between them (fields can drop individually),
          can be determined from the struct
          :ref:`v4l2_buffer <v4l2-buffer>` ``sequence`` field. This
          format cannot be selected when using the read/write I/O method
          since there is no way to communicate if a field was a top or
          bottom field.

    -  .. row 9

       -  ``V4L2_FIELD_INTERLACED_TB``

       -  8

       -  Images contain both fields, interleaved line by line, top field
          first. The top field is transmitted first.

    -  .. row 10

       -  ``V4L2_FIELD_INTERLACED_BT``

       -  9

       -  Images contain both fields, interleaved line by line, top field
          first. The bottom field is transmitted first.



.. _fieldseq-tb:

.. figure::  field-order_files/fieldseq_tb.*
    :alt:    fieldseq_tb.pdf / fieldseq_tb.gif
    :align:  center

    Field Order, Top Field First Transmitted


.. _fieldseq-bt:

.. figure::  field-order_files/fieldseq_bt.*
    :alt:    fieldseq_bt.pdf / fieldseq_bt.gif
    :align:  center

    Field Order, Bottom Field First Transmitted




.. ------------------------------------------------------------------------------
.. This file was automatically converted from DocBook-XML with the dbxml
.. library (https://github.com/return42/sphkerneldoc). The origin XML comes
.. from the linux kernel, refer to:
..
.. * https://github.com/torvalds/linux/tree/master/Documentation/DocBook
.. ------------------------------------------------------------------------------