2020-03-14 02:02:31 +08:00
|
|
|
.. _video_api:
|
drivers: Add video API
This generic video API can be used to capture/output video frames.
Once a video buffer is enqueued to a video device endpoint, device owns
the buffer and can process to capture (camera), output (disk, display),
convert (hw encoder)... User can then call dequeue to retrieve
the processed buffer (video driver ensure cache coherency).
Once dequeued, video buffer is owned by user (e.g. for frame
processing, display buffer update, write to media, etc...).
For each video-buffer, user needs allocate the associated frame buffer
via video_buffer_alloc. Buffer format is defined by video device
endpoint configuration. Video device can be controlled (e.g. contrast,
brightness, flip...) via controls.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
2019-07-01 20:24:25 +08:00
|
|
|
|
|
|
|
Video
|
|
|
|
#####
|
|
|
|
|
|
|
|
The video driver API offers a generic interface to video devices.
|
|
|
|
|
|
|
|
Basic Operation
|
|
|
|
***************
|
|
|
|
|
|
|
|
Video Device
|
|
|
|
============
|
|
|
|
|
|
|
|
A video device is the abstraction of a hardware or software video function,
|
|
|
|
which can produce, process, consume or transform video data. The video API is
|
|
|
|
designed to offer flexible way to create, handle and combine various video
|
|
|
|
devices.
|
|
|
|
|
|
|
|
Endpoint
|
|
|
|
========
|
|
|
|
|
|
|
|
Each video device can have one or more endpoints. Output endpoints configure
|
|
|
|
video output function and generate data. Input endpoints configure video input
|
|
|
|
function and consume data.
|
|
|
|
|
|
|
|
Video Buffer
|
|
|
|
============
|
|
|
|
|
|
|
|
A video buffer provides the transport mechanism for the data. There is no
|
|
|
|
particular requirement on the content. The requirement for the content is
|
|
|
|
defined by the endpoint format. A video buffer can be queued to a device
|
|
|
|
endpoint for filling (input ep) or consuming (output ep) operation, once
|
|
|
|
the operation is achieved, buffer can be dequeued for post-processing,
|
|
|
|
release or reuse.
|
|
|
|
|
|
|
|
Controls
|
|
|
|
========
|
|
|
|
|
|
|
|
A video control is accessed and identified by a CID (control identifier). It
|
|
|
|
represents a video control property. Different devices will have different
|
|
|
|
controls available which can be generic, related to a device class or vendor
|
|
|
|
specific. The set/get control functions provide a generic scalable interface
|
|
|
|
to handle and create controls.
|
|
|
|
|
|
|
|
Configuration Options
|
|
|
|
*********************
|
|
|
|
|
|
|
|
Related configuration options:
|
|
|
|
|
2022-02-08 00:27:43 +08:00
|
|
|
* :kconfig:option:`CONFIG_VIDEO`
|
drivers: Add video API
This generic video API can be used to capture/output video frames.
Once a video buffer is enqueued to a video device endpoint, device owns
the buffer and can process to capture (camera), output (disk, display),
convert (hw encoder)... User can then call dequeue to retrieve
the processed buffer (video driver ensure cache coherency).
Once dequeued, video buffer is owned by user (e.g. for frame
processing, display buffer update, write to media, etc...).
For each video-buffer, user needs allocate the associated frame buffer
via video_buffer_alloc. Buffer format is defined by video device
endpoint configuration. Video device can be controlled (e.g. contrast,
brightness, flip...) via controls.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
2019-07-01 20:24:25 +08:00
|
|
|
|
|
|
|
API Reference
|
|
|
|
*************
|
|
|
|
|
|
|
|
.. doxygengroup:: video_interface
|
|
|
|
|
|
|
|
.. doxygengroup:: video_controls
|