mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-27 23:46:45 +07:00
051f8d2d86
Due to complexity of the video decoding process, the V4L2 drivers of stateful decoder hardware require specific sequences of V4L2 API calls to be followed. These include capability enumeration, initialization, decoding, seek, pause, dynamic resolution change, drain and end of stream. Specifics of the above have been discussed during Media Workshops at LinuxCon Europe 2012 in Barcelona and then later Embedded Linux Conference Europe 2014 in Düsseldorf. The de facto Codec API that originated at those events was later implemented by the drivers we already have merged in mainline, such as s5p-mfc or coda. The only thing missing was the real specification included as a part of Linux Media documentation. Fix it now and document the decoder part of the Codec API. Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
49 lines
2.2 KiB
ReStructuredText
49 lines
2.2 KiB
ReStructuredText
.. Permission is granted to copy, distribute and/or modify this
|
|
.. document under the terms of the GNU Free Documentation License,
|
|
.. Version 1.1 or any later version published by the Free Software
|
|
.. Foundation, with no Invariant Sections, no Front-Cover Texts
|
|
.. and no Back-Cover Texts. A copy of the license is included at
|
|
.. Documentation/media/uapi/fdl-appendix.rst.
|
|
..
|
|
.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections
|
|
|
|
.. _mem2mem:
|
|
|
|
********************************
|
|
Video Memory-To-Memory Interface
|
|
********************************
|
|
|
|
A V4L2 memory-to-memory device can compress, decompress, transform, or
|
|
otherwise convert video data from one format into another format, in memory.
|
|
Such memory-to-memory devices set the ``V4L2_CAP_VIDEO_M2M`` or
|
|
``V4L2_CAP_VIDEO_M2M_MPLANE`` capability. Examples of memory-to-memory
|
|
devices are codecs, scalers, deinterlacers or format converters (i.e.
|
|
converting from YUV to RGB).
|
|
|
|
A memory-to-memory video node acts just like a normal video node, but it
|
|
supports both output (sending frames from memory to the hardware)
|
|
and capture (receiving the processed frames from the hardware into
|
|
memory) stream I/O. An application will have to setup the stream I/O for
|
|
both sides and finally call :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
|
|
for both capture and output to start the hardware.
|
|
|
|
Memory-to-memory devices function as a shared resource: you can
|
|
open the video node multiple times, each application setting up their
|
|
own properties that are local to the file handle, and each can use
|
|
it independently from the others. The driver will arbitrate access to
|
|
the hardware and reprogram it whenever another file handler gets access.
|
|
This is different from the usual video node behavior where the video
|
|
properties are global to the device (i.e. changing something through one
|
|
file handle is visible through another file handle).
|
|
|
|
One of the most common memory-to-memory device is the codec. Codecs
|
|
are more complicated than most and require additional setup for
|
|
their codec parameters. This is done through codec controls.
|
|
See :ref:`mpeg-controls`. More details on how to use codec memory-to-memory
|
|
devices are given in the following sections.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
dev-decoder
|