Lines Matching +full:frame +full:- +full:buffer
14 &VIDIOC-REQBUFS; ioctl. The asynchronous I/O method is not defined
19 selected by initiating video overlay with the &VIDIOC-S-FMT; ioctl.
44 the <structfield>capabilities</structfield> field of &v4l2-capability;
45 returned by the &VIDIOC-QUERYCAP; ioctl is set.</para>
49 necessarily less efficient than other methods merely exchanging buffer
50 pointers. It is considered inferior though because no meta-information
51 like frame counters or timestamps are passed. This information is
52 necessary to recognize frame dropping and to synchronize with other
60 > vidctrl /dev/video --input=0 --format=YUYV --size=352x288
66 &func-read; function, to write the &func-write; function.
75 must also support the &func-select; and &func-poll;
88 <structfield>capabilities</structfield> field of &v4l2-capability;
89 returned by the &VIDIOC-QUERYCAP; ioctl is set. There are two
91 supported applications must call the &VIDIOC-REQBUFS; ioctl.</para>
98 add-on. However, being the most efficient I/O method available for a
100 buffers in DMA-able main memory.</para>
103 identified by a unique buffer type value. The sets are independent and
106 <para>One could use one file descriptor and set the buffer
107 type field accordingly when calling &VIDIOC-QBUF; etc., but it makes
115 &VIDIOC-REQBUFS; ioctl with the desired number of buffers and buffer
122 them into their address space with the &func-mmap; function. The
124 &VIDIOC-QUERYBUF; ioctl. In the single-planar API case, the
126 returned in a &v4l2-buffer; are passed as sixth and second parameter to the
127 <function>mmap()</function> function. When using the multi-planar API,
128 struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each
130 <structfield>length</structfield>. When using the multi-planar API, every
131 plane of every buffer has to be mapped separately, so the number of
132 calls to &func-mmap; should be equal to number of buffers times number of
133 planes in each buffer. The offset and length values must not be modified.
136 as soon as possible with the &func-munmap; function.</para>
139 <title>Mapping buffers in the single-planar API</title>
141 &v4l2-requestbuffers; reqbuf;
153 if (-1 == ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf)) {
155 printf("Video capturing or mmap-streaming is not supported\n");
166 printf("Not enough buffer memory\n");
174 &v4l2-buffer; buffer;
176 memset(&buffer, 0, sizeof(buffer));
177 buffer.type = reqbuf.type;
178 buffer.memory = V4L2_MEMORY_MMAP;
179 buffer.index = i;
181 if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &buffer)) {
186 buffers[i].length = buffer.length; /* remember for munmap() */
188 buffers[i].start = mmap(NULL, buffer.length,
191 fd, buffer.m.offset);
209 <title>Mapping buffers in the multi-planar API</title>
211 &v4l2-requestbuffers; reqbuf;
212 /* Our current format uses 3 planes per buffer */
226 if (ioctl(fd, &VIDIOC-REQBUFS;, &reqbuf) < 0) {
228 printf("Video capturing or mmap-streaming is not supported\n");
239 printf("Not enough buffer memory\n");
247 &v4l2-buffer; buffer;
248 &v4l2-plane; planes[FMT_NUM_PLANES];
250 memset(&buffer, 0, sizeof(buffer));
251 buffer.type = reqbuf.type;
252 buffer.memory = V4L2_MEMORY_MMAP;
253 buffer.index = i;
254 /* length in struct v4l2_buffer in multi-planar API stores the size
256 buffer.length = FMT_NUM_PLANES;
257 buffer.m.planes = planes;
259 if (ioctl(fd, &VIDIOC-QUERYBUF;, &buffer) < 0) {
266 buffers[i].length[j] = buffer.m.planes[j].length; /* remember for munmap() */
268 buffers[i].start[j] = mmap(NULL, buffer.m.planes[j].length,
271 fd, buffer.m.planes[j].m.offset);
290 <para>Conceptually streaming drivers maintain two buffer queues, an incoming
308 drivers to reuse buffers on a LIFO-basis, taking advantage of caches
309 holding scatter-gather lists and the like.</para>
310 </footnote> The index number of a buffer (&v4l2-buffer;
312 identifies the buffer.</para>
317 the read loop. Here the application waits until a filled buffer can be
318 dequeued, and re-enqueues the buffer when the data is no longer
323 buffer can be dequeued and reused.</para>
325 <para>To enqueue and dequeue a buffer applications use the
326 &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. The status of a buffer being
328 &VIDIOC-QUERYBUF; ioctl. Two methods exist to suspend execution of the
330 <constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the
332 given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
333 returns immediately with an &EAGAIN; when no buffer is available. The
334 &func-select; or &func-poll; function are always available.</para>
337 &VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note
341 with another event it should examine the &v4l2-buffer;
369 <structfield>capabilities</structfield> field of &v4l2-capability;
370 returned by the &VIDIOC-QUERYCAP; ioctl is set. If the particular user
372 determined by calling the &VIDIOC-REQBUFS; ioctl.</para>
377 pointers to data are exchanged, these pointers and meta-information
378 are passed in &v4l2-buffer; (or in &v4l2-plane; in the multi-planar API case).
380 &VIDIOC-REQBUFS; with the desired buffer type. No buffers (planes) are allocated
388 &v4l2-requestbuffers; reqbuf;
394 if (ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) {
405 <para>Buffer (plane) addresses and sizes are passed on the fly with the
406 &VIDIOC-QBUF; ioctl. Although buffers are commonly cycled,
411 application in the virtual memory subsystem of the kernel. When buffer
416 scatter-gather lists may be time consuming. The delay can be masked by
417 the depth of the incoming buffer queue, and perhaps by maintaining
418 caches assuming a buffer will be soon enqueued again. On the other
428 &VIDIOC-DQBUF; ioctl. The driver can unlock the memory pages at any
430 also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or
440 Here the application waits until a filled buffer can be dequeued, and
441 re-enqueues the buffer when the data is no longer needed. Output
444 runs out of free buffers it must wait until an empty buffer can be
447 <constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the
449 given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
450 returns immediately with an &EAGAIN; when no buffer is available. The
451 &func-select; or &func-poll; function are always available.</para>
454 &VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note
459 the &v4l2-buffer; <structfield>timestamp</structfield> of captured
481 <section id="buffer">
484 <para>A buffer contains data exchanged by application and
485 driver using one of the Streaming I/O methods. In the multi-planar API, the
486 data is held in planes, while the buffer structure acts as a container
488 itself is not copied. These pointers, together with meta-information like
491 the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl.
492 In the multi-planar API, some plane-specific members of struct
501 sample the system clock shortly after the field or frame was stored
503 difference up to one field or frame period plus a small (few scan
508 field or frame was received by the driver, not the capture time. These
517 the hardware to repeat the previous field or frame, or to display the
518 buffer contents.</para>
531 <table frame="none" pgwide="1" id="v4l2-buffer">
534 &cs-ustr;
540 <entry>Number of the buffer, set by the application. This
543 with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.…
546 <entry>&v4l2-buf-type;</entry>
549 <entry>Type of the buffer, same as &v4l2-format;
550 <structfield>type</structfield> or &v4l2-requestbuffers;
558 buffer. It depends on the negotiated data format and may change with
559 each buffer for compressed variable size data like JPEG images.
568 linkend="buffer-flags" />.</entry>
571 <entry>&v4l2-field;</entry>
575 buffer, see <xref linkend="v4l2-field" />. This field is not used when
576 the buffer contains VBI data. Drivers must set it when
588 nominal frame rate determined by the current video standard in
597 <entry>&v4l2-timecode;</entry>
603 <structfield>flags</structfield>, this structure contains a frame
604 timecode. In <link linkend="v4l2-field">V4L2_FIELD_ALTERNATE</link>
620 linkend="v4l2-field">V4L2_FIELD_ALTERNATE</link> mode the top and
622 and includes dropped or repeated frames. A dropped frame was received
623 by an input device but could not be stored due to lack of free buffer
624 space. A repeated frame was displayed again by an output device
633 <entry>&v4l2-memory;</entry>
647 <entry>For the single-planar API and when
649 is the offset of the buffer from the start of the device memory. The value is
650 returned by the driver and apart of serving as parameter to the &func-mmap;
658 <entry>For the single-planar API and when
660 this is a pointer to the buffer (casted to unsigned long type) in virtual
668 <entry>When using the multi-planar API, contains a userspace pointer
669 to an array of &v4l2-plane;. The size of the array should be put
677 <entry>Size of the buffer (not the payload) in bytes for the
678 single-planar API. For the multi-planar API should contain the
690 number of a video input as in &v4l2-input; field
698 (driver defined) buffer types
706 <table frame="none" pgwide="1" id="v4l2-plane">
709 &cs-ustr;
734 <entry>When the memory type in the containing &v4l2-buffer; is
736 should be passed to &func-mmap;, similar to the
737 <structfield>offset</structfield> field in &v4l2-buffer;.</entry>
743 <entry>When the memory type in the containing &v4l2-buffer; is
766 <table frame="none" pgwide="1" id="v4l2-buf-type">
769 &cs-def;
774 <entry>Buffer of a single-planar video capture stream, see <xref
781 <entry>Buffer of a multi-planar video capture stream, see <xref
787 <entry>Buffer of a single-planar video output stream, see <xref
794 <entry>Buffer of a multi-planar video output stream, see <xref
800 <entry>Buffer for video overlay, see <xref linkend="overlay" />.</entry>
805 <entry>Buffer of a raw VBI capture stream, see <xref
806 linkend="raw-vbi" />.</entry>
811 <entry>Buffer of a raw VBI output stream, see <xref
812 linkend="raw-vbi" />.</entry>
817 <entry>Buffer of a sliced VBI capture stream, see <xref
823 <entry>Buffer of a sliced VBI output stream, see <xref
829 <entry>Buffer for video output overlay (OSD), see <xref
837 (driver defined) buffer types.</entry>
843 <table frame="none" pgwide="1" id="buffer-flags">
844 <title>Buffer Flags</title>
846 &cs-def;
851 <entry>The buffer resides in device memory and has been mapped
854 <link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
855 linkend="vidioc-qbuf">VIDIOC_QBUF</link> or <link
856 linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called. Set by the driver.</entry>
861 <entry>Internally drivers maintain two buffer queues, an
862 incoming and outgoing queue. When this flag is set, the buffer is
864 outgoing queue after the buffer has been filled (capture devices) or
874 <entry>When this flag is set, the buffer is currently on
879 buffer cannot be on both queues at the same time, the
882 They can be both cleared however, then the buffer is in "dequeued"
888 <entry>When this flag is set, the buffer has been dequeued
891 the buffer may be reused normally.
900 capture devices when the buffer contains a compressed image which is a
901 key frame (or field), &ie; can be decompressed on its own.</entry>
908 previous key frame.</entry>
914 this is a bidirectional predicted frame or field. [ooc tbd]</entry>
933 <entry>The buffer has been prepared for I/O and can be queued by the
935 <link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
936 linkend="vidioc-qbuf">VIDIOC_PREPARE_BUF</link>, <link
937 linkend="vidioc-qbuf">VIDIOC_QBUF</link> or <link
938 linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called.</entry>
943 <entry>Caches do not have to be invalidated for this buffer.
944 Typically applications shall use this flag if the data captured in the buffer
945 is not going to be touched by the CPU, instead the buffer will, probably, be
946 passed on to a DMA-capable hardware unit for further processing or output.
952 <entry>Caches do not have to be cleaned for this buffer.
954 in this buffer has not been created by the CPU but by some DMA-capable unit,
961 <table pgwide="1" frame="none" id="v4l2-memory">
964 &cs-def;
969 <entry>The buffer is used for <link linkend="mmap">memory
975 <entry>The buffer is used for <link linkend="userp">user
993 &v4l2-buffer; field <structfield>timestamp</structfield>.)</para>
995 <table frame="none" pgwide="1" id="v4l2-timecode">
998 &cs-str;
1003 <entry>Frame rate the timecodes are based on, see <xref
1004 linkend="timecode-type" />.</entry>
1009 <entry>Timecode flags, see <xref linkend="timecode-flags" />.</entry>
1014 <entry>Frame count, 0 ... 23/24/29/49/59, depending on the
1041 <table frame="none" pgwide="1" id="timecode-type">
1044 &cs-def;
1075 <table frame="none" pgwide="1" id="timecode-flags">
1078 &cs-def;
1083 <entry>Indicates "drop frame" semantics for counting frames
1084 in 29.97 fps material. When set, frame numbers 0 and 1 at the start of
1091 <entry>The "color frame" flag.</entry>
1106 <entry>8-bit ISO characters.</entry>
1114 <section id="field-order">
1123 interleaved, yielding the original frame. This curious technique was
1126 the necessity of doubling the frame rate and with it the bandwidth
1130 one frame at a time, merely transmitting the frames separated into
1134 to recognize which field of a frame is older, the <emphasis>temporal
1141 of the top field is the first line of an interlaced frame, the first
1142 line of the bottom field is the second line of that frame.</para>
1145 arguing whether a frame commences with the top or bottom field is
1147 yield a valid frame. Only when the source was progressive to begin
1149 the same frame, creating a natural order.</para>
1160 <structfield>field</structfield> field of &v4l2-pix-format; before
1161 calling the &VIDIOC-S-FMT; ioctl. If this is not desired it should
1164 <table frame="none" pgwide="1" id="v4l2-field">
1167 &cs-def;
1178 requested image size, and return the actual field order. &v4l2-buffer;
1218 in memory. Image sizes refer to the frame, not fields.</entry>
1226 first in memory. Image sizes refer to the frame, not fields.</entry>
1231 <entry>The two fields of a frame are passed in separate
1234 or application, depending on data direction, must set &v4l2-buffer;
1238 to build a frame. If fields are successive, without any dropped fields
1240 the &v4l2-buffer; <structfield>sequence</structfield> field. Image
1241 sizes refer to the frame, not fields. This format cannot be selected
1242 when using the read/write I/O method.<!-- Where it's indistinguishable
1243 from V4L2_FIELD_SEQ_*. --></entry>
1261 <figure id="fieldseq-tb">
1273 <figure id="fieldseq-bt">