field-order.rst 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166
  1. .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
  2. .. c:namespace:: V4L
  3. .. _field-order:
  4. ***********
  5. Field Order
  6. ***********
  7. We have to distinguish between progressive and interlaced video.
  8. Progressive video transmits all lines of a video image sequentially.
  9. Interlaced video divides an image into two fields, containing only the
  10. odd and even lines of the image, respectively. Alternating the so called
  11. odd and even field are transmitted, and due to a small delay between
  12. fields a cathode ray TV displays the lines interleaved, yielding the
  13. original frame. This curious technique was invented because at refresh
  14. rates similar to film the image would fade out too quickly. Transmitting
  15. fields reduces the flicker without the necessity of doubling the frame
  16. rate and with it the bandwidth required for each channel.
  17. It is important to understand a video camera does not expose one frame
  18. at a time, merely transmitting the frames separated into fields. The
  19. fields are in fact captured at two different instances in time. An
  20. object on screen may well move between one field and the next. For
  21. applications analysing motion it is of paramount importance to recognize
  22. which field of a frame is older, the *temporal order*.
  23. When the driver provides or accepts images field by field rather than
  24. interleaved, it is also important applications understand how the fields
  25. combine to frames. We distinguish between top (aka odd) and bottom (aka
  26. even) fields, the *spatial order*: The first line of the top field is
  27. the first line of an interlaced frame, the first line of the bottom
  28. field is the second line of that frame.
  29. However because fields were captured one after the other, arguing
  30. whether a frame commences with the top or bottom field is pointless. Any
  31. two successive top and bottom, or bottom and top fields yield a valid
  32. frame. Only when the source was progressive to begin with, e. g. when
  33. transferring film to video, two fields may come from the same frame,
  34. creating a natural order.
  35. Counter to intuition the top field is not necessarily the older field.
  36. Whether the older field contains the top or bottom lines is a convention
  37. determined by the video standard. Hence the distinction between temporal
  38. and spatial order of fields. The diagrams below should make this
  39. clearer.
  40. In V4L it is assumed that all video cameras transmit fields on the media
  41. bus in the same order they were captured, so if the top field was
  42. captured first (is the older field), the top field is also transmitted
  43. first on the bus.
  44. All video capture and output devices must report the current field
  45. order. Some drivers may permit the selection of a different order, to
  46. this end applications initialize the ``field`` field of struct
  47. :c:type:`v4l2_pix_format` before calling the
  48. :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. If this is not desired it
  49. should have the value ``V4L2_FIELD_ANY`` (0).
  50. enum v4l2_field
  51. ===============
  52. .. c:type:: v4l2_field
  53. .. tabularcolumns:: |p{5.8cm}|p{0.6cm}|p{10.9cm}|
  54. .. cssclass:: longtable
  55. .. flat-table::
  56. :header-rows: 0
  57. :stub-columns: 0
  58. :widths: 3 1 4
  59. * - ``V4L2_FIELD_ANY``
  60. - 0
  61. - Applications request this field order when any field format
  62. is acceptable. Drivers choose depending on hardware capabilities or
  63. e.g. the requested image size, and return the actual field order.
  64. Drivers must never return ``V4L2_FIELD_ANY``.
  65. If multiple field orders are possible the
  66. driver must choose one of the possible field orders during
  67. :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
  68. :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`. struct
  69. :c:type:`v4l2_buffer` ``field`` can never be
  70. ``V4L2_FIELD_ANY``.
  71. * - ``V4L2_FIELD_NONE``
  72. - 1
  73. - Images are in progressive (frame-based) format, not interlaced
  74. (field-based).
  75. * - ``V4L2_FIELD_TOP``
  76. - 2
  77. - Images consist of the top (aka odd) field only.
  78. * - ``V4L2_FIELD_BOTTOM``
  79. - 3
  80. - Images consist of the bottom (aka even) field only. Applications
  81. may wish to prevent a device from capturing interlaced images
  82. because they will have "comb" or "feathering" artefacts around
  83. moving objects.
  84. * - ``V4L2_FIELD_INTERLACED``
  85. - 4
  86. - Images contain both fields, interleaved line by line. The temporal
  87. order of the fields (whether the top or bottom field is older)
  88. depends on the current video standard. In M/NTSC the bottom
  89. field is the older field. In all other standards the top field
  90. is the older field.
  91. * - ``V4L2_FIELD_SEQ_TB``
  92. - 5
  93. - Images contain both fields, the top field lines are stored first
  94. in memory, immediately followed by the bottom field lines. Fields
  95. are always stored in temporal order, the older one first in
  96. memory. Image sizes refer to the frame, not fields.
  97. * - ``V4L2_FIELD_SEQ_BT``
  98. - 6
  99. - Images contain both fields, the bottom field lines are stored
  100. first in memory, immediately followed by the top field lines.
  101. Fields are always stored in temporal order, the older one first in
  102. memory. Image sizes refer to the frame, not fields.
  103. * - ``V4L2_FIELD_ALTERNATE``
  104. - 7
  105. - The two fields of a frame are passed in separate buffers, in
  106. temporal order, i. e. the older one first. To indicate the field
  107. parity (whether the current field is a top or bottom field) the
  108. driver or application, depending on data direction, must set
  109. struct :c:type:`v4l2_buffer` ``field`` to
  110. ``V4L2_FIELD_TOP`` or ``V4L2_FIELD_BOTTOM``. Any two successive
  111. fields pair to build a frame. If fields are successive, without
  112. any dropped fields between them (fields can drop individually),
  113. can be determined from the struct
  114. :c:type:`v4l2_buffer` ``sequence`` field. This
  115. format cannot be selected when using the read/write I/O method
  116. since there is no way to communicate if a field was a top or
  117. bottom field.
  118. * - ``V4L2_FIELD_INTERLACED_TB``
  119. - 8
  120. - Images contain both fields, interleaved line by line, top field
  121. first. The top field is the older field.
  122. * - ``V4L2_FIELD_INTERLACED_BT``
  123. - 9
  124. - Images contain both fields, interleaved line by line, top field
  125. first. The bottom field is the older field.
  126. .. _fieldseq-tb:
  127. Field Order, Top Field First Transmitted
  128. ========================================
  129. .. kernel-figure:: fieldseq_tb.svg
  130. :alt: fieldseq_tb.svg
  131. :align: center
  132. Field Order, Top Field First Transmitted
  133. .. _fieldseq-bt:
  134. Field Order, Bottom Field First Transmitted
  135. ===========================================
  136. .. kernel-figure:: fieldseq_bt.svg
  137. :alt: fieldseq_bt.svg
  138. :align: center
  139. Field Order, Bottom Field First Transmitted