blob: df2c63d07bac8e81b6c90c2b62a31bd62e9ab37f [file] [log] [blame]
<refentry id="vidioc-streamon">
<refentrytitle>ioctl VIDIOC_STREAMON, VIDIOC_STREAMOFF</refentrytitle>
<refpurpose>Start or stop streaming I/O</refpurpose>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>const int *<parameter>argp</parameter></paramdef>
<para>The <constant>VIDIOC_STREAMON</constant> and
<constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture
or output process during streaming (<link linkend="mmap">memory
mapping</link>, <link linkend="userp">user pointer</link> or
<link linkend="dmabuf">DMABUF</link>) I/O.</para>
<para>Capture hardware is disabled and no input
buffers are filled (if there are any empty buffers in the incoming
queue) until <constant>VIDIOC_STREAMON</constant> has been called.
Output hardware is disabled and no video signal is
produced until <constant>VIDIOC_STREAMON</constant> has been called.
The ioctl will succeed when at least one output buffer is in the
incoming queue.</para>
<para>Memory-to-memory devices will not start until
<constant>VIDIOC_STREAMON</constant> has been called for both the capture
and output stream types.</para>
<para>If <constant>VIDIOC_STREAMON</constant> fails then any already
queued buffers will remain queued.</para>
<para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of
aborting or finishing any DMA in progress, unlocks any user pointer
buffers locked in physical memory, and it removes all buffers from the
incoming and outgoing queues. That means all images captured but not
dequeued yet will be lost, likewise all images enqueued for output but
not transmitted yet. I/O returns to the same state as after calling
&VIDIOC-REQBUFS; and can be restarted accordingly.</para>
<para>If buffers have been queued with &VIDIOC-QBUF; and
<constant>VIDIOC_STREAMOFF</constant> is called without ever having
called <constant>VIDIOC_STREAMON</constant>, then those queued buffers
will also be removed from the incoming queue and all are returned to the
same state as after calling &VIDIOC-REQBUFS; and can be restarted
<para>Both ioctls take a pointer to an integer, the desired buffer or
stream type. This is the same as &v4l2-requestbuffers;
<para>If <constant>VIDIOC_STREAMON</constant> is called when streaming
is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called
when streaming is already stopped, then 0 is returned. Nothing happens in the
case of <constant>VIDIOC_STREAMON</constant>, but <constant>VIDIOC_STREAMOFF</constant>
will return queued buffers to their starting state as mentioned above.</para>
<para>Note that applications can be preempted for unknown periods right
before or after the <constant>VIDIOC_STREAMON</constant> or
<constant>VIDIOC_STREAMOFF</constant> calls, there is no notion of
starting or stopping "now". Buffer timestamps can be used to
synchronize with other events.</para>
<para>The buffer <structfield>type</structfield> is not supported,
or no buffers have been allocated (memory mapping) or enqueued
(output) yet.</para>
<para>The driver implements <link
linkend="pad-level-formats">pad-level format configuration</link> and
the pipeline configuration is invalid.