<div dir="ltr"><div dir="ltr">Hi Alexander,<div><br></div><div>Thanks for the patch! It is a long document, so I skimmed a bit in the first read. Find some comments/questions inlined.</div><div>I will give it a second deeper read soon, but overall I think is in quite good shape. It feels really matured.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 29, 2023 at 4:49 PM Alexander Gordeev <<a href="mailto:Alexander.Gordeev@opensynergy.com" target="_blank">Alexander.Gordeev@opensynergy.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Add the specification of the video decoder and encoder devices, which<br>
can be used to provide host-accelerated video operations to the guest.<br>
<br>
Signed-off-by: Alexander Gordeev <<a href="mailto:Alexander.Gordeev@opensynergy.com" target="_blank">Alexander.Gordeev@opensynergy.com</a>><br>
Co-authored-by: Keiichi Watanabe <<a href="mailto:keiichiw@chromium.org" target="_blank">keiichiw@chromium.org</a>><br>
Co-authored-by: Alexandre Courbot <<a href="mailto:acourbot@chromium.org" target="_blank">acourbot@chromium.org</a>><br>
---<br>
 conformance.tex                           |    4 +<br>
 content.tex                               |    1 +<br>
 device-types/video/description.tex        | 2040 +++++++++++++++++++++<br>
 device-types/video/device-conformance.tex |   22 +<br>
 device-types/video/driver-conformance.tex |   16 +<br>
 introduction.tex                          |   21 +<br>
 6 files changed, 2104 insertions(+)<br>
 create mode 100644 device-types/video/description.tex<br>
 create mode 100644 device-types/video/device-conformance.tex<br>
 create mode 100644 device-types/video/driver-conformance.tex<br>
<br>
diff --git a/conformance.tex b/conformance.tex<br>
index 01ccd69..d719eda 100644<br>
--- a/conformance.tex<br>
+++ b/conformance.tex<br>
@@ -34,6 +34,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}<br>
 \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance},<br>
 \ref{sec:Conformance / Driver Conformance / GPIO Driver Conformance} or<br>
 \ref{sec:Conformance / Driver Conformance / PMEM Driver Conformance}.<br>
+\ref{sec:Conformance / Driver Conformance / Video Driver Conformance},<br>
<br>
     \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.<br>
   \end{itemize}<br>
@@ -61,6 +62,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}<br>
 \ref{sec:Conformance / Device Conformance / SCMI Device Conformance},<br>
 \ref{sec:Conformance / Device Conformance / GPIO Device Conformance} or<br>
 \ref{sec:Conformance / Device Conformance / PMEM Device Conformance}.<br>
+\ref{sec:Conformance / Device Conformance / Video Device Conformance},<br>
<br>
     \item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.<br>
   \end{itemize}<br>
@@ -152,6 +154,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}<br>
 \input{device-types/scmi/driver-conformance.tex}<br>
 \input{device-types/gpio/driver-conformance.tex}<br>
 \input{device-types/pmem/driver-conformance.tex}<br>
+\input{device-types/video/driver-conformance.tex}<br>
<br>
 \conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}<br>
<br>
@@ -238,6 +241,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}<br>
 \input{device-types/scmi/device-conformance.tex}<br>
 \input{device-types/gpio/device-conformance.tex}<br>
 \input{device-types/pmem/device-conformance.tex}<br>
+\input{device-types/video/device-conformance.tex}<br>
<br>
 \conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}<br>
 A conformant implementation MUST be either transitional or<br>
diff --git a/content.tex b/content.tex<br>
index d2ab9eb..90708d7 100644<br>
--- a/content.tex<br>
+++ b/content.tex<br>
@@ -765,6 +765,7 @@ \chapter{Device Types}\label{sec:Device Types}<br>
 \input{device-types/scmi/description.tex}<br>
 \input{device-types/gpio/description.tex}<br>
 \input{device-types/pmem/description.tex}<br>
+\input{device-types/video/description.tex}<br>
<br>
 \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}<br>
<br>
diff --git a/device-types/video/description.tex b/device-types/video/description.tex<br>
new file mode 100644<br>
index 0000000..760df7f<br>
--- /dev/null<br>
+++ b/device-types/video/description.tex<br>
@@ -0,0 +1,2040 @@<br>
+\section{Video Device}<br>
+\label{sec:Device Types / Video Device}<br>
+<br>
+The virtio video encoder and decoder devices provide support for<br>
+host-accelerated video encoding and decoding. Despite being different<br>
+device types, they use the same protocol and general flow.<br>
+<br>
+\subsection{Device ID}<br>
+\label{sec:Device Types / Video Device / Device ID}<br>
+<br>
+\begin{description}<br>
+\item[30]<br>
+  encoder device<br>
+\item[31]<br>
+  decoder device<br>
+\end{description}<br>
+<br>
+\subsection{Virtqueues}<br>
+\label{sec:Device Types / Video Device / Virtqueues}<br>
+<br>
+\begin{description}<br>
+\item[0]<br>
+  commandq - queue for driver commands and device responses to these commands<br>
+\item[1]<br>
+  eventq - queue for device delayed responses to commands and standalone<br>
+  device events<br>
+\end{description}<br>
+<br>
+\subsection{Feature bits}<br>
+\label{sec:Device Types / Video Device / Feature bits}<br>
+<br>
+\begin{description}<br>
+\item[VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES (0)]<br>
+  Guest pages can be used as the backing memory of resources.<br>
+\item[VIRTIO_VIDEO_F_RESOURCE_NON_CONTIG (1)]<br>
+  The device can use non-contiguous guest memory as the backing memory of<br>
+  resources. Only meaningful if VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES is also<br>
+  set.<br>
+\item[VIRTIO_VIDEO_F_RESOURCE_VIRTIO_OBJECT (2)]<br>
+  Objects exported by another virtio device can be used as the backing memory<br>
+  of resources.<br>
+\item[VIRTIO_VIDEO_F_RESOURCE_DYNAMIC (3)]<br>
+  The device supports re-attaching memory to resources while streaming.<br>
+% TODO this flag is not used anywhere at the moment.<br>
+% Might be necessary with Android.<br>
+\end{description}<br></blockquote><div><br></div><div>Maybe I am missing part of the previous dicussion, but is this VIRTIO_VIDEO_F_RESOURCE_DYNAMIC flag new?</div><div>Not sure what re-attaching memory means and what the flag is supossed to do.</div><div>In the comment you mention specifically Android, so it got me curious. What is the usecase for this feature flag?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+<br>
+\devicenormative{\subsubsection}{Feature bits}{Device Types / Video Device / Feature bits}<br>
+<br>
+The device MUST set at least one of VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES or<br>
+VIRTIO_VIDEO_F_RESOURCE_VIRTIO_OBJECT, since the absence of both bits would<br>
+mean that no memory can be used at all for resources.<br>
+<br>
+The device MUST NOT set VIRTIO_VIDEO_F_RESOURCE_NON_CONTIG unless it also sets<br>
+VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES.<br>
+<br>
+\drivernormative{\subsubsection}{Feature bits}{Device Types / Video Device / Feature bits}<br>
+<br>
+The driver MUST negotiate at least one of the<br>
+VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES and VIRTIO_VIDEO_F_RESOURCE_VIRTIO_OBJECT<br>
+features.<br>
+<br>
+If VIRTIO_VIDEO_F_RESOURCE_GUEST_PAGES has been negotiated, but not<br>
+VIRTIO_VIDEO_F_RESOURCE_NON_CONTIG, the driver MUST use physically<br>
+contiguous memory for all the buffers it allocates.<br>
+<br>
+\subsection{Device configuration layout}<br>
+\label{sec:Device Types / Video Device / Device configuration layout}<br>
+<br>
+The video device configuration space uses the following layout:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_config {<br>
+        le32 caps_length;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{caps_length}]<br>
+  is the minimum length in bytes that a device-writable buffer must have<br>
+  in order to receive the response to VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS, see<br>
+  \ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.<br>
+\end{description}<br>
+<br>
+\devicenormative{\subsubsection}{Device configuration layout}{Device Types / Video Device / Device configuration layout}<br>
+<br>
+The device MUST set the \field{caps_length} field to a value equal to<br>
+the response size of VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS.<br>
+<br>
+\subsection{Supported parameters}<br>
+\label{sec:Device Types / Video Device / Supported parameters}<br>
+<br>
+\subsubsection{Supported coded formats}<br>
+\label{sec:Device Types / Video Device / Supported parameters / Supported coded formats}<br>
+<br>
+The following coded formats are defined:<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_CODED_FORMAT_MPEG2  1  /* MPEG-2 Part 2  (V4L2_PIX_FMT_MPEG2) */<br>
+#define VIRTIO_VIDEO_CODED_FORMAT_MPEG4  2  /* MPEG-4 Part 2  (V4L2_PIX_FMT_MPEG4) */<br>
+#define VIRTIO_VIDEO_CODED_FORMAT_H264   3  /* H.264          (V4L2_PIX_FMT_H264)  */<br>
+#define VIRTIO_VIDEO_CODED_FORMAT_HEVC   4  /* HEVC aka H.265 (V4L2_PIX_FMT_HEVC)  */<br>
+#define VIRTIO_VIDEO_CODED_FORMAT_VP8    5  /* VP8            (V4L2_PIX_FMT_VP8)   */<br>
+#define VIRTIO_VIDEO_CODED_FORMAT_VP9    6  /* VP9            (V4L2_PIX_FMT_VP9)   */<br>
+\end{lstlisting}<br>
+<br>
+The above constants have two usages:<br>
+\begin{enumerate}<br>
+\item As bit numbers, used to tell the driver which coded formats are<br>
+supported by the device, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.<br>
+\item As values, used to designate the coded format when working with<br>
+stream parameters, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+\end{enumerate}<br>
+<br>
+The coded formats and the expected data units per buffer are documented in<br>
+\hyperref[intro:V4L2]{V4L2 header} and<br>
+\hyperref[intro:V4L2 compressed]{V4L2 compressed formats documentation}.<br>
+<br>
+\subsubsection{Supported raw formats}<br>
+\label{sec:Device Types / Video Device / Supported parameters / Supported raw formats}<br>
+<br>
+The following raw formats are defined:<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_RAW_FORMAT_ARGB8888  1  /* DRM_FORMAT_ARGB8888 / V4L2_PIX_FMT_ABGR32 */<br>
+#define VIRTIO_VIDEO_RAW_FORMAT_BGRA8888  2  /* DRM_FORMAT_BGRA8888 / V4L2_PIX_FMT_ARGB32 */<br>
+#define VIRTIO_VIDEO_RAW_FORMAT_RGBA8888  3  /* DRM_FORMAT_RGBA8888 / V4L2_PIX_FMT_BGRA32 */<br>
+#define VIRTIO_VIDEO_RAW_FORMAT_NV12      4  /* DRM_FORMAT_NV12     / V4L2_PIX_FMT_NV12   */<br>
+#define VIRTIO_VIDEO_RAW_FORMAT_YUV420    5  /* DRM_FORMAT_YUV420   / V4L2_PIX_FMT_YUV420 */<br>
+#define VIRTIO_VIDEO_RAW_FORMAT_YVU420    6  /* DRM_FORMAT_YVU420   / V4L2_PIX_FMT_YVU420 */<br>
+#define VIRTIO_VIDEO_RAW_FORMAT_YUYV      7  /* DRM_FORMAT_YUYV     / V4L2_PIX_FMT_YUYV   */<br>
+\end{lstlisting}<br>
+<br>
+The above constants have two usages:<br>
+\begin{enumerate}<br>
+\item As bit numbers, used to tell the driver which raw formats are<br>
+supported by the device, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.<br>
+\item As values, used to designate the raw format when working with<br>
+stream parameters, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+\end{enumerate}<br>
+<br>
+The layouts of raw formats are documented in \hyperref[intro:DRM formats]{DRM}<br>
+and \hyperref[intro:V4L2]{V4L2} headers, as well as in<br>
+\hyperref[intro:V4L2 RGB]{V4L2 RGB} and<br>
+\hyperref[intro:V4L2 YUV]{planar YUV} formats documentation.<br>
+<br>
+\subsubsection{Supported stream parameters}<br>
+\label{sec:Device Types / Video Device / Supported parameters / Supported stream parameters}<br>
+<br>
+The following stream parameters are defined:<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_PARAM_CODED_FORMAT       1<br>
+#define VIRTIO_VIDEO_PARAM_RAW_FORMAT         2<br>
+#define VIRTIO_VIDEO_PARAM_CODED_RESOURCES    3<br>
+#define VIRTIO_VIDEO_PARAM_RAW_RESOURCES      4<br>
+#define VIRTIO_VIDEO_PARAM_CROP               5<br>
+#define VIRTIO_VIDEO_PARAM_BITRATE            6  /* Same as V4L2_CID_MPEG_VIDEO_BITRATE */<br>
+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_MPEG2  7<br>
+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_MPEG4  8<br>
+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_H264   9<br>
+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_HEVC   10<br>
+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_VP8    11<br>
+#define VIRTIO_VIDEO_PARAM_GROUP_CODEC_VP9    12<br>
+\end{lstlisting}<br>
+% TODO acourbot: See b/241492607 (fractional frame rates??)<br>
+<br>
+The above constants have two usages:<br>
+\begin{enumerate}<br>
+\item As bit numbers, used to tell the driver which stream parameters are<br>
+supported by the device, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.<br>
+\item As values, used to designate the stream parameters when working with<br>
+them, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+\end{enumerate}<br>
+<br>
+\subsection{Device Initialization}<br>
+\label{sec:Device Types / Video Device / Device Initialization}<br>
+<br>
+\begin{enumerate}<br>
+\def\labelenumi{\arabic{enumi}.}<br>
+\item<br>
+  The driver reads the feature bits and negotiates the features it needs.<br>
+\item<br>
+  The driver sets up the commandq and the eventq.<br>
+\item<br>
+  The driver reads the \field{caps_length} field of the configuration<br>
+  space and prepares a buffer of at least that size.<br>
+\item<br>
+  The driver sends that buffer on the commandq with the<br>
+  VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS command.<br>
+\item<br>
+  The driver receives the response from the device, and parses its capabilities.<br>
+\end{enumerate}<br>
+<br>
+\subsection{Device Operation}<br>
+\label{sec:Device Types / Video Device / Device Operation}<br>
+<br>
+The commandq is used by the driver to send commands to the device and to<br>
+receive the device's responses via used buffers. The eventq is used by the<br>
+device to send the device's delayed responses to commands and standalone<br>
+device events.<br>
+<br>
+The driver can create new streams using the<br>
+VIRTIO_VIDEO_CMD_STREAM_CREATE command. Each stream has two resource<br>
+queues (not to be confused with the virtio queues) called INPUT and<br>
+OUTPUT, when the direction of the data flow matters. The INPUT queue accepts<br>
+driver-filled input data for the device (coded data for a decoder;<br>
+input frames for an encoder), while the OUTPUT queue receives resources to be<br>
+filled by the device as a result of processing the INPUT queue (decoded raw<br>
+frames for a decoder; encoded data for an encoder).<br>
+<br>
+These same queues can be also called CODED and RAW, when their content matters.<br>
+The CODED queue is used to transfer compressed video data (INPUT for a decoder;<br>
+OUTPUT for an encoder), while the RAW queue is used to transfer raw frames<br>
+(OUTPUT for a decoder; INPUT for an encoder).<br>
+<br>
+The INPUT and OUTPUT queues are effectively independent, and the driver<br>
+can fill them without caring about the other queue. In particular there<br>
+is no need to queue input and output resources in pairs: one input<br>
+resource can result in zero to many produced output resources.<br>
+<br>
+A resource is a set of memory buffers that contain a unit of data that<br>
+the device can process or produce. Most resources will only have one<br>
+buffer (like coded data and single-planar raw frames), but frames using a<br>
+multi-planar format can have several.<br>
+<br>
+Parameters allow the driver to configure the stream for the decoding or<br>
+encoding operation. The parameters can be obtained and configured using<br>
+VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS. Available parameters depend on<br>
+the device type and are detailed in section<br>
+\ref{sec:Device Types / Video Device / Supported parameters / Supported stream parameters}.<br>
+<br>
+Before resources can be submitted to a queue, backing memory must be<br>
+attached to them using VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING.<br>
+The exact form of that memory is negotiated using the feature flags.<br>
+<br>
+In the case of a decoder device, the decoded frames are made available<br>
+on the OUTPUT queue in presentation order.<br>
+<br>
+Resources are queued to the INPUT or OUTPUT queue using the<br>
+VIRTIO_VIDEO_CMD_RESOURCE_QUEUE command. The device sends a delayed response<br>
+to this command when an input resource has been fully processed and can be<br>
+reused by the driver, or when an output resource has been filled by the<br>
+device as a result of processing.<br>
+<br>
+The device can detect stream-related events that require intervention<br>
+from the driver and signals them on the eventq, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events}.<br>
+One example is a dynamic parameters change while decoding a stream, which<br>
+may require the driver to reallocate the backing memory of its output<br>
+resources to fit the new resolution.<br>
+<br>
+% RESET and DRAIN have essentially the same outcome: all the input<br>
+% resources queued before the command are released, there are no related<br>
+% output resources in the decoder/encoder, the dequeued output resources<br>
+% can't be used as a reference by the device. So the other requirements should<br>
+% be reasonably similar.<br>
+% Use-case: playback in a loop from second 1 till the end of file.<br>
+<br>
+% TODO put some examples in the comments<br>
+<br>
+\subsubsection{Device Operation: Command Virtqueue}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+<br>
+This section details the commands that can be sent on the commandq by<br>
+the driver, as well as the responses that the device will write.<br>
+<br>
+Different structures are used for each command and response. A command<br>
+structure starts with the requested command code, defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+/* Device */<br>
+#define VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS       0x100<br>
+<br>
+/* Stream */<br>
+#define VIRTIO_VIDEO_CMD_STREAM_CREATE           0x200<br>
+#define VIRTIO_VIDEO_CMD_STREAM_DESTROY          0x201<br>
+#define VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS       0x202<br></blockquote><div><br></div><div>Why not having a GET_PARAMS counterpart?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+#define VIRTIO_VIDEO_CMD_STREAM_DRAIN            0x203<br>
+#define VIRTIO_VIDEO_CMD_STREAM_RESET            0x204<br>
+<br>
+/* Resource */<br>
+#define VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING 0x300<br>
+#define VIRTIO_VIDEO_CMD_RESOURCE_QUEUE          0x301<br>
+\end{lstlisting}<br>
+<br>
+A response structure starts with the result of the requested command,<br>
+defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+/* Success */<br>
+#define VIRTIO_VIDEO_RESULT_OK                          0x000<br>
+#define VIRTIO_VIDEO_RESULT_OK_DELAYED                  0x001<br>
+<br>
+/* Error */<br>
+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_COMMAND         0x100<br>
+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION       0x101<br>
+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_STREAM_ID       0x102<br>
+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_RESOURCE_ID     0x103<br>
+#define VIRTIO_VIDEO_RESULT_ERR_INVALID_ARGUMENT        0x104<br>
+#define VIRTIO_VIDEO_RESULT_ERR_OUT_OF_MEMORY           0x105<br>
+\end{lstlisting}<br>
+<br>
+For response structures carrying an error code, the rest of the<br>
+structure is considered invalid.<br>
+<br>
+For all commands beginning background operations and returning delayed<br>
+responses over eventq, the command response is defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_INVALID_RESPONSE_ID  0xffffffff<br>
+<br>
+struct virtio_video_command_resp_delayed_common {<br>
+        le32 result; /* VIRTIO_VIDEO_RESULT_* */<br>
+        le32 delayed_response_id;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{result}]<br>
+  is<br>
+<br>
+  \begin{description}<br>
+  \item[VIRTIO_VIDEO_RESULT_OK_DELAYED]<br>
+    if the command started the desired background operation successfully,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_STREAM_ID]<br>
+    if the mentioned stream ID does not exist,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_RESOURCE_ID]<br>
+    if the mentioned resource ID does not exist,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_ARGUMENT]<br>
+    if other command parameters are not valid, e.g. not within the device's<br>
+    capabilities,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION]<br>
+    if the command is performed at a time when it is not valid.<br>
+  \end{description}<br>
+\item[\field{delayed_response_id}]<br>
+  is an ID of the future delayed response provided by the device, that allows<br>
+  to relate it to the command.<br>
+\end{description}<br>
+<br>
+\devicenormative{\paragraph}{Device Operation: Command Virtqueue}{Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+<br>
+Responses to a command MUST be written by the device in the first<br>
+device-writable descriptor of the descriptor chain from which the<br>
+command came.<br>
+<br>
+The device MUST return VIRTIO_VIDEO_RESULT_ERR_INVALID_COMMAND to<br>
+any command code it does not recognize.<br>
+<br>
+\field{delayed_response_id} MUST be set to a stream-unique identifier that<br>
+remains valid as long as the background operation hasn't finished.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+<br>
+\drivernormative{\paragraph}{Device Operation: Command Virtqueue}{Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+<br>
+Descriptor chains sent to the commandq by the driver MUST include at<br>
+least one device-writable descriptor of a size sufficient to receive the<br>
+response to the queued command.<br>
+<br>
+The driver MUST NOT interpret the rest of a response whose result is not<br>
+VIRTIO_VIDEO_RESULT_OK or VIRTIO_VIDEO_RESULT_OK_DELAYED.<br>
+<br>
+\subsubsection{Device Operation: Event Virtqueue}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}<br>
+<br>
+The eventq is used by the device to send delayed responses to commands queued<br>
+by the driver on the commandq and standalone events. Stream errors and dynamic<br>
+parameters changes are caused by changes in the device's state, not by<br>
+commands, still they are delivered as VIRTIO_VIDEO_DELAYED_RESP_STREAM_DESTROY<br>
+and VIRTIO_VIDEO_DELAYED_RESP_STREAM_SET_PARAMS, respectively.<br></blockquote><div><br></div><div>So, ERROR and DRC events trigger a VIRTIO_VIDEO_DELAYED_RESP_STREAM_DESTROY</div><div>and VIRTIO_VIDEO_DELAYED_RESP_STREAM_SET_PARAMS events, respectively.</div><div>And VIRTIO_VIDEO_DELAYED_RESP_STREAM_SET_PARAMS will have</div><div>a valid `delayed_response_id` only if it comes from a SET_PARAMS command from the</div><div>driver. Otherwise, if it is due to a dynamic parameter change, `delayed_response_id`</div><div>will be set to `VIRTIO_VIDEO_INVALID_RESPONSE_ID`. Is this correct?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+<br>
+The supported events are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_DELAYED_RESP_STREAM_DESTROY     1<br>
+#define VIRTIO_VIDEO_DELAYED_RESP_STREAM_SET_PARAMS  2<br>
+#define VIRTIO_VIDEO_DELAYED_RESP_STREAM_DRAIN       3<br>
+#define VIRTIO_VIDEO_DELAYED_RESP_STREAM_RESET       4<br>
+#define VIRTIO_VIDEO_DELAYED_RESP_RESOURCE_QUEUE     5<br>
+<br>
+#define VIRTIO_VIDEO_EVENT_FLAG_CANCELED             (1 << 0)<br>
+<br>
+struct virtio_video_event {<br>
+        le32 event_type; /* VIRTIO_VIDEO_DELAYED_RESP_* */<br>
+        le32 stream_id;<br>
+        le32 delayed_response_id;<br>
+        le32 event_flags; /* Bitmask of VIRTIO_VIDEO_EVENT_FLAG_* */<br>
+        union {<br>
+                struct virtio_video_stream_set_params_delayed_resp set_params;<br>
+                struct virtio_video_resource_queue_delayed_resp queue;<br>
+        };<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{event_type}]<br>
+  is the type of the event.<br>
+\item[\field{stream_id}]<br>
+  is the ID of a valid stream.<br>
+\item[\field{delayed_response_id}]<br>
+  is an ID of the delayed response, that allows to relate it to a previously<br>
+  submitted command. If it is set to VIRTIO_VIDEO_INVALID_RESPONSE_ID, then<br>
+  this is a standalone event, see<br>
+  \ref{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events}.<br>
+\item[\field{event_flags}]<br>
+  is a bitmask of VIRTIO_VIDEO_EVENT_FLAG_* flags<br>
+<br>
+  \begin{description}<br>
+  \item[VIRTIO_VIDEO_EVENT_FLAG_CANCELED]<br>
+    is set if the command has been canceled by another command, that has<br>
+    higher priority. Doesn't make sense for standalone events.<br>
+  \end{description}<br>
+\end{description}<br>
+<br>
+The particular member of the union is selected according to the<br>
+\field{event_type} for some of the types.<br>
+<br>
+\drivernormative{\paragraph}{Device Operation: Event Virtqueue}{Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}<br>
+<br>
+The driver MUST at any time have at least one descriptor with a used<br>
+buffer large enough to contain a \field{struct virtio_video_event}<br>
+queued on the eventq.<br>
+<br>
+The driver MUST NOT put device-readable descriptors into the eventq.<br>
+<br>
+\subsubsection{Device Operation: Device Commands}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands}<br>
+<br>
+This command allows retrieving the device capabilities.<br>
+<br>
+\paragraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}<br>
+<br>
+Retrieve device capabilities for all available stream parameters.<br>
+<br>
+The driver sends this command with<br>
+\field{struct virtio_video_device_query_caps}:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_device_query_caps {<br>
+        le32 cmd_type; /* VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS */<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+The device responds with<br>
+\field{struct virtio_video_device_query_caps_resp}:<br>
+<br>
+\begin{lstlisting}<br>
+#define MASK(x) (1 << (x))<br>
+<br>
+struct virtio_video_device_query_caps_resp {<br>
+        le32 result; /* VIRTIO_VIDEO_RESULT_* */<br>
+        le32 stream_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_PARAM_*) */<br>
+        le32 coded_formats_bitmask; /* Bitmaks of MASK(VIRTIO_VIDEO_CODED_FORMAT_*) */<br>
+        le32 raw_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_RAW_FORMAT_*) */<br>
+        le32 num_format_deps;<br>
+        le32 num_raw_format_caps;<br>
+        le32 num_coded_resources_caps;<br>
+        le32 num_raw_resources_caps;<br>
+        le32 num_bitrate_caps; /* If MASK(VIRTIO_VIDEO_PARAM_BITRATE) is set. */<br>
+        u8 padding[4];<br>
+        /* If corresponding MASK(VIRTIO_VIDEO_PARAM_GROUP_CODEC_*) is set. */<br>
+        struct virtio_video_mpeg2_caps mpeg2_caps;<br>
+        struct virtio_video_mpeg4_caps mpeg4_caps;<br>
+        struct virtio_video_h264_caps h264_caps;<br>
+        struct virtio_video_hevc_caps hevc_caps;<br>
+        struct virtio_video_vp8_caps vp8_caps;<br>
+        struct virtio_video_vp9_caps vp9_caps;<br>
+        /**<br>
+         * Followed by<br>
+         * struct virtio_video_format_dependency format_deps[num_format_deps];<br>
+         */<br>
+        /**<br>
+         * Followed by<br>
+         * struct virtio_video_raw_format_caps raw_format_caps[num_raw_format_caps];<br>
+         */<br>
+        /**<br>
+         * Followed by<br>
+         * struct virtio_video_coded_resources_caps<br>
+         * coded_resources_caps[num_coded_resources_caps];<br>
+         */<br>
+        /**<br>
+         * Followed by<br>
+         * struct virtio_video_raw_resources_caps raw_resources_caps[num_raw_resources_caps];<br>
+         */<br>
+        /**<br>
+         * Followed by if MASK(VIRTIO_VIDEO_PARAM_BITRATE) is set<br>
+         * struct virtio_video_bitrate_caps bitrate_caps[num_bitrate_caps];<br>
+         */<br>
+};<br></blockquote><div><br></div><div>Maybe nitpicking, but some of the member structs are inside a comment and some are not.</div><div>Does not seem to correlate with them being conditional.</div><div>I think is nice to have conditional fields in comment blocks to highlight it, but then the</div><div>VIRTIO_VIDEO_PARAM_GROUP_CODEC_* structs need to be in their own comment block.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{result}]<br>
+  is<br>
+<br>
+  \begin{description}<br>
+  \item[VIRTIO_VIDEO_RESULT_OK]<br>
+    if the operation succeeded,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_OUT_OF_MEMORY]<br>
+    if the descriptor was smaller than the defined \field{caps_length} in<br>
+    the video device configuration.<br>
+  \end{description}<br>
+\item[\field{stream_params_bitmask}]<br>
+  is a bitmask of supported stream parameters.<br>
+\item[\field{coded_formats_bitmask}]<br>
+  is a bitmask of supported coded formats.<br>
+\item[\field{raw_formats_bitmask}]<br>
+  is a bitmask of supported raw formats.<br>
+\item[\field{num_format_deps}]<br>
+  is the number of elements in the format_deps array.<br>
+\item[\field{num_raw_format_caps}]<br>
+  is the number of elements in the raw_format_caps array.<br>
+\item[\field{num_coded_resources_caps}]<br>
+  is the number of elements in the coded_resources_caps array.<br>
+\item[\field{num_raw_resources_caps}]<br>
+  is the number of elements in the raw_resources_caps array.<br>
+\item[\field{num_bitrate_caps}]<br>
+  is the number of elements in the bitrate_caps array.<br>
+\item[\field{mpeg2_caps}]<br>
+  groups the capabilities of MPEG2 specific parameters.<br>
+\item[\field{mpeg4_caps}]<br>
+  groups the capabilities of MPEG4 specific parameters.<br>
+\item[\field{h264_caps}]<br>
+  groups the capabilities of H.264 specific parameters.<br>
+\item[\field{hevc_caps}]<br>
+  groups the capabilities of HEVC specific parameters.<br>
+\item[\field{vp8_caps}]<br>
+  groups the capabilities of VP8 specific parameters.<br>
+\item[\field{vp9_caps}]<br>
+  groups the capabilities of VP9 specific parameters.<br>
+\item[\field{format_deps}]<br>
+  is an array of size \field{num_format_deps} establishing dependencies<br>
+  between coded and raw formats.<br>
+\item[\field{raw_format_caps}]<br>
+  is an array of size \field{num_raw_format_caps} containing the supported<br>
+  raw formats capabilities.<br>
+\item[\field{coded_resources_caps}]<br>
+  is an array of size \field{num_coded_resources_caps}, that sets bounds for<br>
+  the number of resources in the CODED queue.<br>
+\item[\field{raw_resources_caps}]<br>
+  is an array of size \field{num_raw_resources_caps}, that sets bounds for<br>
+  the number of resources in the RAW queue.<br>
+\item[\field{bitrate_caps}]<br>
+  is an array of size \field{num_bitrate_caps} containing the supported<br>
+  bitrates.<br>
+\end{description}<br>
+<br>
+% TODO: V4L2 flow: 1. coded format without variants (maybe these flags<br>
+% are relevant too: V4L2_FMT_FLAG_CONTINUOUS_BYTESTREAM?,<br>
+% V4L2_FMT_FLAG_DYN_RESOLUTION?, V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL???),<br>
+% also include variants (see VIDIOC_QUERYCTRL), then raw formats,<br>
+% then resolutions (discrete or stepwise, see VIDIOC_ENUM_FRAMESIZES),<br>
+% intervals are optional (see VIDIOC_ENUM_FRAMEINTERVALS)<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}<br>
+<br>
+The device MUST support at least these parameters:<br>
+VIRTIO_VIDEO_PARAM_CODED_FORMAT, VIRTIO_VIDEO_PARAM_RAW_FORMAT,<br>
+VIRTIO_VIDEO_PARAM_CODED_RESOURCES, VIRTIO_VIDEO_PARAM_RAW_RESOURCES.<br>
+<br>
+The device MUST NOT mark codec-specific parameters<br>
+(VIRTIO_VIDEO_PARAM_GROUP_CODEC_*) as supported unless the corresponding<br>
+codecs are supported as well.<br>
+<br>
+The device MUST set to zero all fields with capabilities of unsupported<br>
+parameters.<br>
+<br>
+The lengths \field{num_format_deps}, \field{num_raw_format_caps},<br>
+\field{num_coded_resources_caps} and \field{num_raw_resources_caps} MUST be<br>
+positive.<br>
+<br>
+The device MUST write the five \field{format_deps},<br>
+\field{raw_format_caps}, \field{coded_resources_caps},<br>
+\field{raw_resources_caps} and \field{bitrate_caps} arrays, of length<br>
+\field{num_format_deps}, \field{num_raw_format_caps},<br>
+\field{num_coded_resources_caps}, \field{num_raw_resources_caps} and<br>
+\field{num_bitrate_caps}, respectively.<br>
+<br>
+For each coded format in the \field{coded_formats_bitmask} there MUST be<br>
+at least one element of \field{format_deps} referencing it.<br>
+<br>
+For each raw format in the \field{raw_formats_bitmask} there MUST be<br>
+at least one element of \field{format_deps} referencing it.<br>
+<br>
+For any coded and any raw format there MUST be at most one element of<br>
+\field{format_deps} referencing both of them.<br>
+<br>
+Elements of \field{format_deps} SHOULD be ordered according to raw format<br>
+preferences of the device from preferred to not preferred ones.<br>
+<br>
+For each raw format in the \field{raw_formats_bitmask} there MUST be<br>
+exactly one element of \field{raw_format_caps} referencing it.<br>
+<br>
+For each coded format in the \field{coded_formats_bitmask} there MUST be<br>
+exactly one element of \field{coded_resources_caps} referencing it.<br>
+<br>
+For each raw format in the \field{raw_formats_bitmask} there MUST be<br>
+exactly one element of \field{raw_resources_caps} referencing it.<br>
+<br>
+If VIRTIO_VIDEO_PARAM_BITRATE is supported, then for each coded format in<br>
+the \field{coded_formats_bitmask} there MUST be exactly one element of<br>
+\field{bitrate_caps} referencing it.<br>
+<br>
+The total size of the response MUST be equal to \field{caps_length}<br>
+bytes, as reported by the device configuration.<br>
+<br>
+\subparagraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Format dependencies}<br>
+<br>
+The description of dependencies between coded and raw formats<br>
+\field{virtio_video_format_dependency} is defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_format_dependency {<br>
+        le32 coded_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_CODED_FORMAT_*) */<br>
+        le32 raw_format; /* VIRTIO_VIDEO_RAW_FORMAT_* */<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{coded_formats_bitmask}]<br>
+  specifies coded formats, see<br>
+  \ref{sec:Device Types / Video Device / Supported parameters / Supported coded formats}.<br>
+  If a bit for a specific coded format is set, then this coded format can be<br>
+  decoded into the specified raw format or encoded from it.<br>
+\item[\field{raw_format}]<br>
+  is a raw format, see<br>
+  \ref{sec:Device Types / Video Device / Supported parameters / Supported raw formats}.<br>
+\end{description}<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Format dependencies}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Format dependencies}<br>
+<br>
+\field{coded_formats_bitmask} MUST be a subset of \field{coded_formats_bitmask}<br>
+field of \field{struct virtio_video_device_query_caps_resp}.<br>
+<br>
+\field{coded_formats_bitmask} MUST specify at least one coded format.<br>
+<br>
+\field{raw_format} MUST be set to one of the supported raw formats according to<br>
+the \field{raw_formats_bitmask} field of<br>
+\field{struct virtio_video_device_query_caps_resp}.<br>
+<br>
+\subparagraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}<br>
+<br>
+The raw format capability description \field{virtio_video_raw_format_caps} is<br>
+defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+enum virtio_video_planes_layout {<br>
+        VIRTIO_VIDEO_PLANES_LAYOUT_SINGLE_BUFFER = 1,<br>
+        VIRTIO_VIDEO_PLANES_LAYOUT_MULTI_BUFFERS = 2,<br>
+};<br>
+<br>
+struct virtio_video_range {<br>
+        le32 min;<br>
+        le32 max;<br>
+        le32 step;<br>
+        u8 padding[4];<br>
+};<br>
+<br>
+struct virtio_video_raw_format_caps {<br>
+        le32 raw_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_RAW_FORMAT_*) */<br>
+        le32 planes_layouts; /* Bitmask of VIRTIO_VIDEO_PLANES_LAYOUT_* */<br>
+        le32 plane_align;<br>
+        le32 stride_align_mask;<br>
+        struct virtio_video_range width_range;<br>
+        struct virtio_video_range height_range;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\field{struct virtio_video_range} is used to represent a range of values.<br>
+An integer \(x\) is within the range \field{r} if<br>
+\(\field{r.min} \le x \le \field{r.max}\) holds and \(x\) equals to<br>
+\((\field{min} + \field{step} * n)\) for some integer \(n\).<br>
+<br>
+\begin{description}<br>
+\item[\field{raw_formats_bitmask}]<br>
+  specifies raw formats, see<br>
+  \ref{sec:Device Types / Video Device / Supported parameters / Supported raw formats},<br>
+  to which these capabilities apply.<br>
+\item[\field{planes_layouts}]<br>
+  is a bitmask with the set of plane layout types from<br>
+  \field{enum virtio_video_planes_layout}.<br>
+\item[\field{plane_align}]<br>
+  is the alignment of planes within a buffer in bytes. This field is valid<br>
+  only if \field{planes_layouts} has the<br>
+  \field{VIRTIO_VIDEO_PLANES_LAYOUT_SINGLE_BUFFER} bit set.<br>
+\item[\field{stride_align_mask}]<br>
+  is a mask of all supported power of two stride alignments.<br>
+\item[\field{width_range}]<br>
+  is a range of widths in pixels.<br>
+\item[\field{height_range}]<br>
+  is a range of heights in pixels.<br>
+\end{description}<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}<br>
+<br>
+\field{raw_formats_bitmask} MUST be a subset of \field{raw_formats_bitmask}<br>
+field of \field{struct virtio_video_device_query_caps_resp}.<br>
+<br>
+\field{raw_formats_bitmask} MUST specify at least one raw format.<br>
+<br>
+The device MUST set \field{VIRTIO_VIDEO_PLANES_LAYOUT_SINGLE_BUFFER} bit in<br>
+\field{planes_layouts} if the plane layout with planes of a frame laid out one<br>
+after another in the same buffer is supported.<br>
+<br>
+The device MUST set \field{VIRTIO_VIDEO_PLANES_LAYOUT_MULTI_BUFFERS} bit in<br>
+\field{planes_layouts} if the plane layout with planes of a frame laid out in<br>
+separate buffers is supported.<br>
+<br>
+\field{plane_align} MUST be set to a power of two according to the device<br>
+plane alignment requirements if \field{planes_layouts} has the<br>
+\field{VIRTIO_VIDEO_PLANES_LAYOUT_SINGLE_BUFFER} bit set or to zero otherwise.<br>
+<br>
+\field{min}, \field{step} and \field{max} MUST be positive.<br>
+<br>
+\field{min} MUST be less then or equal to \field{max} within the same range.<br>
+<br>
+\subparagraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Resource capabilities}<br>
+<br>
+The CODED resource capabilities \field{virtio_video_coded_resources_caps} is<br>
+defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_coded_resources_caps {<br>
+        le32 coded_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_CODED_FORMAT_*) */<br>
+        le32 min_resources;<br>
+        le32 max_resources;<br>
+        le32 buffer_size;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{coded_formats_bitmask}]<br>
+  specifies coded formats, see<br>
+  \ref{sec:Device Types / Video Device / Supported parameters / Supported coded formats},<br>
+  to which these capabilities apply.<br>
+\item[\field{min_resources}]<br>
+  is the minimum number of resources that the CODED queue supports for all<br>
+  the specified coded formats.<br>
+\item[\field{max_resources}]<br>
+  is the maximum number of resources that the CODED queue supports for all<br>
+  the specified coded formats.<br>
+\item[\field{buffer_size}]<br>
+  is the minimum size of the buffers that will back resources to be queued.<br>
+\end{description}<br>
+<br>
+The RAW resource capabilities \field{virtio_video_raw_resources_caps} is<br>
+defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_raw_resources_caps {<br>
+        le32 raw_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_RAW_FORMAT_*) */<br>
+        le32 min_resources;<br>
+        le32 max_resources;<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{raw_formats_bitmask}]<br>
+  specifies raw formats, see<br>
+  \ref{sec:Device Types / Video Device / Supported parameters / Supported raw formats},<br>
+  to which these capabilities apply.<br>
+\item[\field{min_resources}]<br>
+  is the minimum number of resources that the RAW queue supports for all<br>
+  the specified raw formats.<br>
+\item[\field{max_resources}]<br>
+  is the maximum number of resources that the RAW queue supports for all<br>
+  the specified raw formats.<br>
+\end{description}<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Resource capabilities}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Resource capabilities}<br>
+<br>
+\field{coded_formats_bitmask} MUST be a subset of \field{coded_formats_bitmask}<br>
+field of \field{struct virtio_video_device_query_caps_resp}.<br>
+<br>
+\field{coded_formats_bitmask} MUST specify at least one coded format.<br>
+<br>
+\field{raw_formats_bitmask} MUST be a subset of \field{raw_formats_bitmask}<br>
+field of \field{struct virtio_video_device_query_caps_resp}.<br>
+<br>
+\field{raw_formats_bitmask} MUST specify at least one raw format.<br>
+<br>
+\field{min_resources} MUST NOT be negative.<br>
+<br>
+\field{max_resources} MUST be greater then or equal to \field{min_resources}<br>
+within the same struct instance.<br>
+<br>
+\subparagraph{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Bitrates}<br>
+<br>
+The bitrate capabilities \field{virtio_video_bitrate_caps} is<br>
+defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_bitrate_caps {<br>
+        le32 coded_formats_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_CODED_FORMAT_*) */<br>
+        le32 min_bitrate;<br>
+        le32 max_bitrate;<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{coded_formats_bitmask}]<br>
+  specifies coded formats, see<br>
+  \ref{sec:Device Types / Video Device / Supported parameters / Supported coded formats},<br>
+  to which these capabilities apply.<br>
+\item[\field{min_bitrate}]<br>
+  is the minimum bitrate in bits per second supported by the encoder for all the specified coded<br>
+  formats.<br>
+\item[\field{max_bitrate}]<br>
+  is the maximum bitrate in bits per second supported by the encoder for all the specified coded<br>
+  formats.<br>
+\end{description}<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Bitrates}{Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Bitrates}<br>
+<br>
+\field{coded_formats_bitmask} MUST be a subset of \field{coded_formats_bitmask}<br>
+field of \field{struct virtio_video_device_query_caps_resp}.<br>
+<br>
+\field{coded_formats_bitmask} MUST specify at least one coded format.<br>
+<br>
+\field{min_bitrate} MUST NOT be negative.<br>
+<br>
+\field{max_bitrate} MUST be greater then or equal to \field{min_bitrate}<br>
+within the same \field{struct virtio_video_bitrate_caps} instance.<br>
+<br>
+\subsubsection{Device Operation: Stream commands}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands}<br>
+<br>
+Stream commands allow the creation, destruction, and flow control of a<br>
+stream.<br>
+<br>
+\paragraph{VIRTIO_VIDEO_CMD_STREAM_CREATE}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_CREATE}<br>
+<br>
+Create a new stream using the device.<br>
+<br>
+The driver sends this command with<br>
+\field{struct virtio_video_stream_create}:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_stream_create {<br>
+        le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_CREATE */<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+The device responds with \field{struct virtio_video_stream_create_resp}:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_stream_create_resp {<br>
+        le32 result; /* VIRTIO_VIDEO_RESULT_* */<br>
+        le32 stream_id;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{result}]<br>
+  is<br>
+<br>
+  \begin{description}<br>
+  \item[VIRTIO_VIDEO_RESULT_OK]<br>
+    if the operation succeeded,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_OUT_OF_MEMORY]<br>
+    if the limit of simultaneous streams has been reached by the device and<br>
+    no more can be created.<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION]<br>
+    if the stream cannot be created due to an unexpected device issue.<br>
+  \end{description}<br>
+\item[\field{stream_id}]<br>
+  is the ID of the created stream allocated by the device.<br>
+\end{description}<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_CREATE}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_CREATE}<br>
+<br>
+\field{stream_id} MUST be set to a device-unique identifier that remains<br>
+valid as long as the stream is alive.<br>
+<br>
+\paragraph{VIRTIO_VIDEO_CMD_STREAM_DESTROY}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}<br>
+<br>
+% DESTROY has to be more like RESET, not DRAIN, because it is called, for<br>
+% example, when the guest user-space app closes a file descriptor. So there<br>
+% is no sense in continuing the processing.<br>
+<br>
+Destroy a video stream and all its resources. Any activity on the stream<br>
+is halted and all resources are released by the time the delayed response is<br>
+received by the driver.<br>
+<br>
+The driver sends this command with<br>
+\field{struct virtio_video_stream_destroy}:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_stream_destroy {<br>
+        le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_DESTROY */<br>
+        le32 stream_id;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{stream_id}]<br>
+  is the ID of the stream to be destroyed, as previously returned by<br>
+  VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+\end{description}<br>
+<br>
+The device responds as described in<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+and begins the background DESTROY operation.<br>
+<br>
+When the command is completed the device sends the<br>
+VIRTIO_VIDEO_DELAYED_RESP_STREAM_DESTROY delayed response, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.<br>
+The delayed response can also come in case of unrecoverable stream error, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events / Error Event}.<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_DESTROY}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}<br>
+<br>
+Before the device sends a delayed response to VIRTIO_VIDEO_CMD_STREAM_DESTROY,<br>
+it MUST send all other pending delayed responses with<br>
+VIRTIO_VIDEO_EVENT_FLAG_CANCELED flag set and detach all resources.<br>
+<br>
+After VIRTIO_VIDEO_CMD_STREAM_DESTROY is queued, the device MUST reply with<br>
+VIRTIO_VIDEO_RESULT_ERR_INVALID_STREAM_ID to any subsequently queued command<br>
+with this stream ID.<br>
+<br>
+The DESTROY operation MUST NOT be canceled.<br>
+<br>
+\drivernormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_DESTROY}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}<br>
+<br>
+\field{stream_id} MUST be set to a valid stream ID previously returned<br>
+by VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+<br>
+The driver MUST stop using \field{stream_id} as a valid stream after it<br>
+received the delayed response to this command.<br>
+<br>
+\paragraph{VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}<br>
+<br>
+Write values of selected parameters of a given stream, and receive back the<br>
+values for all the parameters supported by the device as reported by<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.<br>
+The operation can be either executed immediately, or queued into the INPUT<br>
+queue, i.e. after processing all the INPUT queue elements that are queued<br>
+before the command.<br>
+<br>
+The driver sends this command with<br>
+\field{struct virtio_video_stream_set_params}:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_SET_PARAMS_FLAG_IN_BAND  (1 << 0)<br>
+<br>
+struct virtio_video_stream_set_params {<br>
+        le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS */<br>
+        le32 stream_id;<br>
+        le32 flags; /* Bitmask of VIRTIO_VIDEO_SET_PARAMS_FLAG_* */<br>
+        u8 padding[4];<br>
+        struct virtio_video_params params;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{stream_id}]<br>
+  is the ID of the stream we want to set a parameter for.<br>
+\item[\field{flags}]<br>
+  is a bitmask of VIRTIO_VIDEO_SET_PARAMS_FLAG_* values.<br>
+<br>
+  \begin{description}<br>
+  \item[\field{VIRTIO_VIDEO_SET_PARAMS_FLAG_IN_BAND}]<br>
+    The submitted parameters are to be set only after all of the previously<br>
+    queued INPUT queue elements are processed. Without this flag the<br>
+    parameters are set Immediately.<br>
+  \end{description}<br>
+\item[\field{params}]<br>
+  is a container for the selected stream parameters to be set.<br>
+\end{description}<br>
+<br>
+The device responds as described in<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+and begins the background SET_PARAMS operation.<br>
+<br>
+When the background processing of the resource is completed the device sends<br>
+the VIRTIO_VIDEO_DELAYED_RESP_STREAM_SET_PARAMS delayed response, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.<br>
+The delayed response can also come in case of dynamic parameters change, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events / Dynamic Parameters Change Event}.<br>
+<br>
+The command-specific delayed response<br>
+\field{struct virtio_video_stream_set_params_delayed_resp} is defined<br>
+as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_stream_set_params_delayed_resp {<br>
+        struct virtio_video_params params;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{params}]<br>
+  is a container for the actual values of all the parameters supported by the<br>
+  device. The values set by the device may differ from the requested values<br>
+  depending on the device's capabilities.<br>
+\end{description}<br>
+<br>
+The \field{struct virtio_video_params} is defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_raw_format {<br>
+        le32 format;<br>
+        le32 planes_layout; /* VIRTIO_VIDEO_PLANES_LAYOUT_* */<br>
+        le32 stride;<br>
+        le32 width;<br>
+        le32 height;<br>
+        u8 padding[4];<br>
+};<br>
+<br>
+struct virtio_video_param_crop {<br>
+        le32 left;<br>
+        le32 top;<br>
+        le32 width;<br>
+        le32 height;<br>
+};<br>
+<br>
+union virtio_video_codec_params {<br>
+        struct virtio_video_mpeg2_params mpeg2;<br>
+        struct virtio_video_mpeg4_params mpeg4;<br>
+        struct virtio_video_h264_params h264;<br>
+        struct virtio_video_hevc_params hevc;<br>
+        struct virtio_video_vp8_params vp8;<br>
+        struct virtio_video_vp9_params vp9;<br>
+};<br>
+<br>
+struct virtio_video_params {<br>
+        le32 stream_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_PARAM_*) */<br>
+        le32 coded_format; /* If MASK(VIRTIO_VIDEO_PARAM_CODED_FORMAT) is set. */<br>
+        /* If MASK(VIRTIO_VIDEO_PARAM_RAW_FORMAT) is set. */<br>
+        struct virtio_video_raw_format raw_format;<br>
+        /* If MASK(VIRTIO_VIDEO_PARAM_CODED_RESOURCES) is set. */<br>
+        struct virtio_video_param_resources coded_resources;<br>
+        /* If MASK(VIRTIO_VIDEO_PARAM_RAW_RESOURCES) is set. */<br>
+        struct virtio_video_param_resources raw_resources;<br>
+        struct virtio_video_param_crop crop; /* If MASK(VIRTIO_VIDEO_PARAM_CROP) is set. */<br>
+        le32 bitrate; /* If MASK(VIRTIO_VIDEO_PARAM_BITRATE) is set. */<br>
+        u8 padding[4];<br>
+        /* If the corresponding MASK(VIRTIO_VIDEO_PARAM_GROUP_CODEC_*) is set<br>
+        * depending on the coded_format. */<br>
+        union virtio_video_codec_params codec;<br>
+};<br>
+\end{lstlisting}<br></blockquote><div><br></div><div>This is a bit difficult to read for me, as some of the *if* comments are written AFTER</div><div>the member definition, and some others BEFORE the member defintion.</div><div>Above, when introducing the VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS command,</div><div>you use this format for the conditional fields:</div><div>/**<br>* Followed by if MASK(VIRTIO_VIDEO_PARAM_BITRATE) is set<br>* struct virtio_video_bitrate_caps bitrate_caps[num_bitrate_caps];<br>*/<br></div><div>It spaces a bit more the members, and leaves them as part of the</div><div>comment block. I would suggest to keep the format consistent.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+<br>
+\begin{description}<br>
+\item[\field{stream_params_bitmask}]<br>
+  is a bitmask of supported stream parameters.<br>
+\item[\field{coded_format}]<br>
+  is a coded format of the CODED queue, see<br>
+  \ref{sec:Device Types / Video Device / Supported parameters}.<br>
+\item[\field{raw_format}]<br>
+  is a raw format of the RAW queue including related parameters<br>
+<br>
+  \begin{description}<br>
+  \item[\field{format}]<br>
+    is the actual format, see<br>
+    \ref{sec:Device Types / Video Device / Supported parameters / Supported raw formats}.<br>
+  \item[\field{planes_layout}]<br>
+    is the actual layout of the planes, see<br>
+    \ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}.<br>
+  \item[\field{stride}]<br>
+    is the distance in bytes between two lines of data.<br>
+  \item[\field{width}]<br>
+    is the width in pixels of the stream frames.<br>
+  \item[\field{height}]<br>
+    is the height in pixels of the stream frames.<br>
+  \end{description}<br>
+\item[\field{coded_resources}]<br>
+  is the CODED queue resources parameters, see<br>
+  \ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+\item[\field{raw_resources}]<br>
+  is the RAW queue resources parameters, see<br>
+  \ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+\item[\field{crop}]<br>
+  is the rectangle covering the visible size of the frame, i.e the part of<br>
+  the frame that should be displayed, \field{width} and \field{height} are<br>
+  relative to \field{left} and \field{top}.<br>
+\item[\field{bitrate}]<br>
+  is the current desired bitrate for the encoder. This can be changed at<br>
+  any moment by the driver and will apply to subsequently submitted frames.<br>
+\item[\field{codec}]<br>
+  consists of codec-specific parameters, see<br>
+  \ref{sec:Device Types / Video Device / Codec-specific parameters} for the<br>
+  definitions. Not available until \field{coded_format} is set.<br>
+\end{description}<br>
+<br>
+Successfully setting \field{coded_format}, \field{coded_resources},<br>
+\field{raw_format} or \field{raw_resources} starts with an implicit<br>
+background DRAIN operation if the corresponding queue has any queued<br>
+resources, then all the remaining elements in the queue are cancelled if<br>
+there are any and then all currently attached resources of the queue are<br>
+detached if there are any, i.e. the driver cannot queue a resource to the<br>
+queue without attaching some backing memory first.<br>
+<br>
+% Use-case: for the decoder, resolution can be set manually by the driver<br>
+% (useful for codecs that do not embed this information). The processing<br>
+% sequence should the look similar to the dynamic parameters change case.<br>
+<br>
+\field{struct virtio_video_param_resources} is used to control the<br>
+number of resources and their backing memory type for the INPUT and<br>
+OUTPUT queues:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_MEM_TYPE_GUEST_PAGES       0x1<br>
+#define VIRTIO_VIDEO_MEM_TYPE_VIRTIO_OBJECT     0x2<br>
+<br>
+struct virtio_video_param_resources {<br>
+        le32 num_resources;<br>
+        u8 mem_type; /* VIRTIO_VIDEO_MEM_TYPE_* */<br>
+        u8 padding[3];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{num_resources}]<br>
+  is the number of resources that can be addressed for the queue, numbered<br>
+  from \(0\) to \(num\_resources - 1\). Can be equal to zero if no<br>
+  resources are allocated, otherwise will be comprised between<br>
+  \field{min_resources} and \field{max_resources}.<br>
+\item[\field{mem_type}]<br>
+  is the memory type that will be used to back these resources.<br>
+\end{description}<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}<br>
+<br>
+The device MUST initialize each parameter to a valid default value.<br>
+<br>
+The device MUST allow each parameter to be read even without the driver<br>
+explicitly setting a value for them beforehand.<br>
+<br>
+\field{stream_params_bitmask} MUST be a subset of \field{stream_params_bitmask}<br>
+field of \field{struct virtio_video_device_query_caps_resp}.<br>
+<br>
+The fields \field{coded_format}, \field{raw_format}, \field{coded_resources},<br>
+\field{raw_resources}, \field{bitrate}, \field{codec} MUST be set according<br>
+to the capabilities returned by VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}.<br>
+The conformance check MUST be performed before the command response is sent.<br>
+<br>
+\field{stream_params_bitmask} MAY contain at most one of<br>
+VIRTIO_VIDEO_PARAM_GROUP_CODEC_* bits. This bit MUST correspond to the<br>
+coded format selected with \field{coded_format}.<br>
+<br>
+The device MAY adjust any requested parameter to a closest supported<br>
+value if the requested one is not supported with the current settings.<br>
+<br>
+There MAY be at most one out of band SET_PARAMS operations at the same time.<br>
+The amount of in band SET_PARAMS operations at the same time MUST NOT exceed<br>
+the number of input resources.<br>
+<br>
+The parameters MUST be applied in the same order as in<br>
+\ref{sec:Device Types / Video Device / Supported parameters / Supported stream parameters}.<br>
+<br>
+When \field{coded_format}, \field{coded_resources},<br>
+\field{raw_format} or \field{raw_resources} are being changed, the device<br>
+MUST first check if there are any queued resources in the corresponding<br>
+queue. If there are any the device MUST run a DRAIN operation in the same way<br>
+as with VIRTIO_VIDEO_CMD_STREAM_DRAIN except that sending<br>
+VIRTIO_VIDEO_DELAYED_RESP_STREAM_DRAIN MUST be omitted. Then the device MUST<br>
+cancel all remaining elements in the queue if there are any. Then the device<br>
+MUST detach all attached resources of the queue if there are any. Then the<br>
+device MUST set the requested parameters and send the delayed response. Any<br>
+subsequent operations using the queue MUST be blocked until the first<br>
+resource is attached and queued again. All these steps MUST be performed<br>
+before processing any subsequent commands.<br>
+<br>
+The device MUST process parameters changes, that are embedded in the input<br>
+stream, in the same way as if there is an in band<br>
+VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS command changing the OUTPUT queue<br>
+parameters. A standalone DPC event MUST be sent instead of the command's<br>
+delayed response in this case.<br>
+<br>
+The device MUST return all the available parameters in the delayed response<br>
+to the command. \field{codec} is not available until \field{coded_format}<br>
+is set.<br>
+<br>
+% TODO define when changing other parameters is allowed.<br>
+<br>
+\drivernormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}<br>
+<br>
+\field{stream_id} MUST be set to a valid stream ID previously returned<br>
+by VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+<br>
+The driver MUST fill the fields according to the parameters selected with<br>
+\field{stream_params_bitmask}. All the other fields MUST be set to zero.<br>
+<br>
+The driver MUST check the actual values of the parameters as set by the<br>
+device and work with these values, or try to set a different one if it<br>
+cannot, or fail properly.<br>
+<br>
+After creating a new stream, the initial value of all parameters is<br>
+undefined to the driver. Thus, the driver MUST NOT assume the default<br>
+value of any parameter and MAY use VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS<br>
+in order to get the values of the parameters it needs.<br>
+<br>
+The driver SHOULD NOT send any in band SET_PARAMS commands or QUEUE commands<br>
+on the INPUT queue before receiving the delayed response, when changing the<br>
+\field{coded_format} or \field{coded_resources} for decoder or<br>
+\field{raw_format} or \field{raw_resources} for encoder.<br>
+<br>
+If some of the resources were detached as a result of this command the<br>
+driver SHOULD maybe reallocate and reattach the backing memories of these<br>
+resources and queue them again to resume the device operation.<br>
+<br>
+\paragraph{VIRTIO_VIDEO_CMD_STREAM_DRAIN}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}<br>
+<br>
+Complete processing of all INPUT queue elements queued before this command<br>
+and make the resulting output resources available to the driver.<br>
+<br>
+The driver sends this command with<br>
+\field{struct virtio_video_stream_drain}:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_stream_drain {<br>
+        le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_DRAIN */<br>
+        le32 stream_id;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{stream_id}]<br>
+  is the ID of the stream to drain, as previously returned by<br>
+  VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+\end{description}<br>
+<br>
+The device responds as described in<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+and begins the background DRAIN operation.<br>
+<br>
+When the background DRAIN operation is completed the device sends the<br>
+VIRTIO_VIDEO_DELAYED_RESP_STREAM_DRAIN delayed response, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_DRAIN}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}<br>
+<br>
+Before the device sends the response, it MUST process and respond to all<br>
+the VIRTIO_VIDEO_CMD_RESOURCE_QUEUE commands on the INPUT queue that<br>
+were sent before the drain command, and make all the corresponding<br>
+output resources available to the driver by responding to their<br>
+VIRTIO_VIDEO_CMD_RESOURCE_QUEUE command.<br>
+<br>
+The device MUST be able to accept input work while a DRAIN operation<br>
+is ongoing, but any resulting delayed responses MUST NOT be sent before<br>
+the delayed response to the DRAIN command.<br>
+<br>
+The amount of DRAIN operations at the same time in the INPUT queue MUST NOT<br>
+exceed the number of input resources. The device MUST return<br>
+VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION if the number is exceeded.<br>
+<br>
+If the command is interrupted with a VIRTIO_VIDEO_CMD_STREAM_RESET<br>
+or VIRTIO_VIDEO_CMD_STREAM_DESTROY commands, the device MUST<br>
+send the delayed response with VIRTIO_VIDEO_EVENT_FLAG_CANCELED flag set.<br>
+<br>
+\drivernormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_DRAIN}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}<br>
+<br>
+\field{stream_id} MUST be set to a valid stream ID previously returned<br>
+by VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+<br>
+The driver MUST keep queueing output resources until it gets the<br>
+response to this command or cancels it using<br>
+VIRTIO_VIDEO_CMD_STREAM_RESET or<br>
+VIRTIO_VIDEO_CMD_STREAM_DESTROY. Failure to do so may result in the<br>
+device stalling as it waits for output resources to write into.<br>
+<br>
+The driver MUST account for the fact that the response to this command<br>
+might come out-of-order (i.e. after other commands sent to the device),<br>
+and that it can be interrupted.<br>
+<br>
+The driver MUST send a DRAIN command when it does not have any further<br>
+input, in order to ensure it receives all the output corresponding to<br>
+the stream.<br>
+<br>
+\paragraph{VIRTIO_VIDEO_CMD_STREAM_RESET}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}<br>
+<br>
+Immediately cancel all INPUT queue elements queued before this command<br>
+without processing them and discard any processing results in the output<br>
+resources, that are not yet dequeued. This command is mostly useful for<br>
+decoders that need to quickly jump from one point of the stream to another<br>
+(i.e. seeking), or in order to stop processing as quickly as possible.<br>
+<br>
+The driver sends this command with<br>
+\field{struct virtio_video_stream_reset}:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_stream_reset {<br>
+        le32 cmd_type; /* VIRTIO_VIDEO_CMD_STREAM_RESET */<br>
+        le32 stream_id;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{stream_id}]<br>
+  is the ID of the stream to reset, as previously returned by<br>
+  VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+\end{description}<br>
+<br>
+The device responds as described in<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+and begins the background RESET operation.<br>
+<br>
+When the background RESET operation is completed the device sends the<br>
+VIRTIO_VIDEO_DELAYED_RESP_STREAM_RESET delayed response, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_RESET}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}<br>
+<br>
+The device MUST send delayed responses with VIRTIO_VIDEO_EVENT_FLAG_CANCELED<br>
+flag set for a background DRAIN operation and VIRTIO_VIDEO_CMD_RESOURCE_QUEUE<br>
+commands on the INPUT queue before responding to this command.<br>
+<br>
+While the device is processing the command, it MUST return<br>
+VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION to any subsequent<br>
+VIRTIO_VIDEO_CMD_STREAM_RESET commands.<br>
+<br>
+The device MUST be able to accept input work while a RESET operation<br>
+is ongoing, but any resulting delayed responses MUST NOT be sent before<br>
+the delayed response to the RESET command.<br>
+<br>
+The device MUST interrupt operation as quickly as possible, and not be<br>
+dependent on output resources being queued by the driver.<br>
+<br>
+Upon resuming processing, the device MAY skip input data until it finds<br>
+a point that allows it to resume operation properly (e.g. until a<br>
+keyframe is found in the input stream of a decoder).<br>
+<br>
+\drivernormative{\subparagraph}{VIRTIO_VIDEO_CMD_STREAM_RESET}{Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}<br>
+<br>
+\field{stream_id} MUST be set to a valid stream ID previously returned<br>
+by VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+<br>
+Upon receiving the response to this command, the driver SHOULD process<br>
+(or drop) any output resource before resuming operation by queueing new<br>
+input resources.<br>
+<br>
+Upon receiving the response to this command, the driver MAY modify the<br>
+\field{struct virtio_video_param_resources} parameter corresponding to<br>
+the INPUT queue, and subsequently attach new backing memory to the input<br>
+resources using the VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING<br>
+command.<br>
+<br>
+\subsubsection{Device Operation: Resource Commands}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Resource Commands}<br>
+<br>
+Resource commands manage the memory backing of individual resources and<br>
+queue them for the device to process.<br>
+<br>
+\paragraph{VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}<br>
+<br>
+Attach backing memory to a resource.<br>
+<br>
+The driver sends this command with<br>
+\field{struct virtio_video_resource_attach_backing}:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_QUEUE_TYPE_INPUT       0<br>
+#define VIRTIO_VIDEO_QUEUE_TYPE_OUTPUT      1<br>
+<br>
+struct virtio_video_resource_attach_backing {<br>
+        le32 cmd_type; /* VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING */<br>
+        le32 stream_id;<br>
+        le32 queue_type; /* VIRTIO_VIDEO_QUEUE_TYPE_* */<br>
+        le32 resource_id;<br>
+        union virtio_video_resource resources[];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{stream_id}]<br>
+  is the ID of a valid stream.<br>
+\item[\field{queue_type}]<br>
+  is the direction of the queue.<br>
+\item[\field{resource_id}]<br>
+  is the ID of the resource to be attached to.<br>
+\item[\field{resources}]<br>
+  specifies memory regions to attach.<br>
+% TODO add number of resources?<br>
+\end{description}<br>
+<br>
+The union \field{virtio_video_resource} is defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+union virtio_video_resource {<br>
+        struct virtio_video_resource_sg_list sg_list;<br>
+        struct virtio_video_resource_object object;<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{sg_list}]<br>
+  represents a scatter-gather list. This variant can be used when the<br>
+  \field{mem_type} member of the \field{virtio_video_param_resources}<br>
+  corresponding to the queue is set to<br>
+  VIRTIO_VIDEO_MEM_TYPE_GUEST_PAGES, see<br>
+  \ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+\item[\field{object}]<br>
+  represents an object exported from another virtio device as defined in<br>
+  \ref{sec:Basic Facilities of a Virtio Device / Exporting Objects}.<br>
+  This variant can be used when the \field{mem_type} member of the<br>
+  \field{virtio_video_param_resources} corresponding to the queue is set<br>
+  to VIRTIO_VIDEO_MEM_TYPE_VIRTIO_OBJECT, see<br>
+  \ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+\end{description}<br>
+<br>
+The struct \field{virtio_video_resource_sg_list} is defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_resource_sg_entry {<br>
+        le64 addr;<br>
+        le32 length;<br>
+        u8 padding[4];<br>
+};<br>
+<br>
+struct virtio_video_resource_sg_list {<br>
+        le32 num_entries;<br>
+        u8 padding[4];<br>
+        /* Followed by num_entries instances of<br>
+           virtio_video_resource_sg_entry */<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+Within \field{struct virtio_video_resource_sg_entry}:<br>
+<br>
+\begin{description}<br>
+\item[\field{addr}]<br>
+  is a guest physical address to the start of the SG entry. Must be<br>
+  aligned to the size of physical guest pages.<br>
+\item[\field{length}]<br>
+  is the length of the SG entry in bytes. Must be aligned to the size<br>
+  of physical guest pages.<br>
+\end{description}<br>
+<br>
+Finally, for \field{struct virtio_video_resource_sg_list}:<br>
+<br>
+\begin{description}<br>
+\item[\field{num_entries}]<br>
+  is the number of \field{struct virtio_video_resource_sg_entry} instances<br>
+  that follow.<br>
+\end{description}<br>
+<br>
+\field{struct virtio_video_resource_object} is defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_resource_object {<br>
+        u8 uuid[16];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[uuid]<br>
+  is a version 4 UUID specified by \hyperref[intro:rfc4122]{[RFC4122]}.<br>
+\end{description}<br>
+<br>
+The device responds with<br>
+\field{struct virtio_video_resource_attach_backing_resp}:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_resource_attach_backing_resp {<br>
+        le32 result; /* VIRTIO_VIDEO_RESULT_* */<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{result}]<br>
+  is<br>
+<br>
+  \begin{description}<br>
+  \item[VIRTIO_VIDEO_RESULT_OK]<br>
+    if the operation succeeded,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_STREAM_ID]<br>
+    if the mentioned stream does not exist,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_RESOURCE_ID]<br>
+    if the mentioned resource does not exist,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_ARGUMENT]<br>
+    if \field{queue_type} or \field{resources} have an invalid value,<br>
+  \item[VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION]<br>
+    if the operation is performed at a time when it is not valid.<br>
+  \end{description}<br>
+\end{description}<br>
+<br>
+VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING can only be called during<br>
+the following times:<br>
+<br>
+\begin{itemize}<br>
+\item<br>
+  AFTER a VIRTIO_VIDEO_CMD_STREAM_CREATE and BEFORE invoking<br>
+  VIRTIO_VIDEO_CMD_RESOURCE_QUEUE for the first time on the<br>
+  resource,<br>
+\item<br>
+  AFTER successfully changing the \field{virtio_video_param_resources}<br>
+  parameter corresponding to the queue and BEFORE<br>
+  VIRTIO_VIDEO_CMD_RESOURCE_QUEUE is called again on the resource.<br>
+\end{itemize}<br>
+<br>
+This is to ensure that the device can rely on the fact that a given<br>
+resource will always point to the same memory for as long as it may be<br>
+used by the video device. For instance, a decoder may use returned<br>
+decoded frames as reference for future frames and won't overwrite the<br>
+backing resource of a frame that is being referenced. It is only before<br>
+a stream is started and after a Dynamic Parameters Change event has<br>
+occurred that we can be sure that all resources won't be used in that<br>
+way.<br>
+<br>
+% TODO add a requirement for the driver or the device to handle a case<br>
+% when a still referenced frame is queued again. So that it is less likely<br>
+% to be forgotten.<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}{Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}<br>
+<br>
+At any time other than the times valid for calling this command, the<br>
+device MUST return VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION.<br>
+<br>
+\drivernormative{\subparagraph}{VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}{Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}<br>
+<br>
+\field{stream_id} MUST be set to a valid stream ID previously returned<br>
+by VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+<br>
+\field{queue_type} MUST be set to a valid queue type.<br>
+<br>
+\field{resource_id} MUST be an integer inferior to the number of<br>
+resources currently allocated for the queue.<br>
+<br>
+The length of the \field{resources} array of<br>
+\field{struct virtio_video_resource_attach_backing} MUST be equal to the<br>
+number of resources required by the format currently set on the queue,<br>
+as described in<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+<br>
+\paragraph{VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}<br>
+<br>
+Add a resource to the device's queue.<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_MAX_PLANES                    8<br>
+<br>
+#define VIRTIO_VIDEO_ENQUEUE_FLAG_FORCE_KEY_FRAME  (1 << 0)<br>
+<br>
+struct virtio_video_resource_queue {<br>
+        le32 cmd_type; /* VIRTIO_VIDEO_CMD_RESOURCE_QUEUE */<br>
+        le32 stream_id;<br>
+        le32 queue_type; /* VIRTIO_VIDEO_QUEUE_TYPE_* */<br>
+        le32 resource_id;<br>
+        le32 flags; /* Bitmask of VIRTIO_VIDEO_ENQUEUE_FLAG_* */<br>
+        u8 padding[4];<br>
+        le64 timestamp;<br>
+        le32 offsets[VIRTIO_VIDEO_MAX_PLANES];<br>
+        le32 data_sizes[VIRTIO_VIDEO_MAX_PLANES];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{stream_id}]<br>
+  is the ID of a valid stream.<br>
+\item[\field{queue_type}]<br>
+  is the direction of the queue.<br>
+\item[\field{resource_id}]<br>
+  is the ID of the resource to be queued.<br>
+\item[\field{flags}]<br>
+  is a bitmask of VIRTIO_VIDEO_ENQUEUE_FLAG_* values.<br>
+<br>
+  \begin{description}<br>
+  \item[\field{VIRTIO_VIDEO_ENQUEUE_FLAG_FORCE_KEY_FRAME}]<br>
+    The submitted frame is to be encoded as a key frame. Only valid for the<br>
+    encoder's INPUT queue.<br>
+  \end{description}<br>
+\item[\field{timestamp}]<br>
+  is an abstract sequence counter that can be used on the INPUT queue for<br>
+  synchronization. Resources produced on the output queue will carry the<br>
+  \field{timestamp} of the first input resource they have been produced<br>
+  from.<br>
+% TODO take note about timestamps from V4L2 spec<br>
+\item[\field{offsets}]<br>
+  is the starting offset for the data in the buffer for each plane.<br>
+  The number of planes depends on the format. Set by the driver for input<br>
+  resources.<br>
+\item[\field{data_sizes}]<br>
+  is number of data bytes used for each plane. Set by the driver for input<br>
+  resources.<br>
+\end{description}<br>
+<br>
+The device responds as described in<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+and puts the resource in the selected queue for background processing.<br>
+<br>
+When the background processing of the resource is completed the device sends<br>
+the VIRTIO_VIDEO_DELAYED_RESP_RESOURCE_QUEUE delayed response, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}.<br>
+<br>
+The command-specific delayed response<br>
+\field{struct virtio_video_resource_queue_delayed_resp} is defined<br>
+as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_DEQUEUE_FLAG_ERR           (1 << 0)<br>
+/* Encoder only */<br>
+#define VIRTIO_VIDEO_DEQUEUE_FLAG_KEY_FRAME     (1 << 1)<br>
+#define VIRTIO_VIDEO_DEQUEUE_FLAG_P_FRAME       (1 << 2)<br>
+#define VIRTIO_VIDEO_DEQUEUE_FLAG_B_FRAME       (1 << 3)<br>
+<br>
+struct virtio_video_resource_queue_delayed_resp {<br>
+        le32 queue_type; /* VIRTIO_VIDEO_QUEUE_TYPE_* */<br>
+        le32 resource_id;<br>
+        le32 flags;<br>
+        u8 padding[4];<br>
+        le64 timestamp;<br>
+        le32 offsets[VIRTIO_VIDEO_MAX_PLANES];<br>
+        le32 data_sizes[VIRTIO_VIDEO_MAX_PLANES];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{queue_type}]<br>
+  is the direction of the queue.<br>
+\item[\field{resource_id}]<br>
+  is the ID of the dequeued resource.<br>
+\item[\field{flags}]<br>
+  is a bitmask of VIRTIO_VIDEO_DEQUEUE_FLAG_* flags.<br>
+<br>
+  \begin{description}<br>
+  \item[VIRTIO_VIDEO_DEQUEUE_FLAG_ERR]<br>
+    is set on resources when a non-fatal processing error has happened and<br>
+    the data contained by the resource is likely to be corrupted,<br>
+  \item[VIRTIO_VIDEO_DEQUEUE_FLAG_KEY_FRAME]<br>
+    is set on output resources when the resource contains an encoded key<br>
+    frame (only for encoders).<br>
+  \item[VIRTIO_VIDEO_DEQUEUE_FLAG_P_FRAME]<br>
+    is set on output resources when the resource contains only differences<br>
+    to a previous key frame (only for encoders).<br>
+  \item[VIRTIO_VIDEO_DEQUEUE_FLAG_B_FRAME]<br>
+    is set on output resources when the resource contains only the<br>
+    differences between the current frame and both the preceding and<br>
+    following key frames (only for encoders).<br>
+  \end{description}<br>
+\item[\field{timestamp}]<br>
+  is set on output resources to the \field{timestamp} value of the input<br>
+  resource that produced the resource.<br>
+\item[\field{offsets}]<br>
+  is set on output resources to the starting offset for the data in the<br>
+  buffer for each plane.<br>
+\item[\field{data_sizes}]<br>
+  is set on output resources to the amount of data written by the device,<br>
+  for each plane.<br>
+\end{description}<br>
+<br>
+\devicenormative{\subparagraph}{VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}{Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}<br>
+<br>
+The device MUST return VIRTIO_VIDEO_RESULT_ERR_INVALID_OPERATION if<br>
+VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING has not been<br>
+successfully called on the resource prior to queueing it or for an<br>
+attempt to queue a resources that is still processed in background.<br>
+<br>
+The device MUST mark resources that might contain corrupted content due to<br>
+an error with the VIRTIO_VIDEO_BUFFER_FLAG_ERR flag.<br>
+<br>
+For output resources, the device MUST copy the \field{timestamp}<br>
+parameter of the input resource that produced it into its response.<br>
+% TODO rephrase?<br>
+<br>
+In case of encoder, the device MUST mark each output resource with one<br>
+of VIRTIO_VIDEO_DEQUEUE_FLAG_KEY_FRAME,<br>
+VIRTIO_VIDEO_DEQUEUE_FLAG_P_FRAME, or<br>
+VIRTIO_VIDEO_DEQUEUE_FLAG_B_FRAME.<br>
+<br>
+If the processing of a resource was stopped due to a stream event, a<br>
+VIRTIO_VIDEO_CMD_STREAM_RESET, or a VIRTIO_VIDEO_CMD_STREAM_DESTROY,<br>
+the device MUST send the corresponding delayed responses with<br>
+VIRTIO_VIDEO_EVENT_FLAG_CANCELED flag set.<br>
+<br>
+\drivernormative{\subparagraph}{VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}{Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}<br>
+<br>
+\field{stream_id} MUST be set to a valid stream ID previously returned<br>
+by VIRTIO_VIDEO_CMD_STREAM_CREATE.<br>
+<br>
+\field{queue_type} MUST be set to a valid queue type.<br>
+<br>
+\field{resource_id} MUST be an integer inferior to the number of<br>
+resources currently allocated for the queue.<br>
+<br>
+The driver MUST account for the fact that the response to this command<br>
+might come out-of-order (i.e. after other commands sent to the device),<br>
+and that it can be interrupted.<br>
+<br>
+% TODO acourbot: The driver and device MUST follow requirements about<br>
+% buffer ownership explained in<br>
+% \ref{sec:Device Types / Video Device / Device Operation / Buffer lifecycle}.<br>
+<br>
+\subsubsection{Device Operation: Standalone Events}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events}<br>
+<br>
+These events are caused by state changes in the device, not as a delayed<br>
+response to any command.<br>
+<br>
+\paragraph{Error Event}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events / Error Event}<br>
+<br>
+The error event is sent by the device when an unrecoverable error occurs<br>
+during processing a stream. The device operation is exactly the same as when<br>
+it receives a VIRTIO_VIDEO_CMD_STREAM_DESTROY command, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}.<br>
+Note that this is different from dequeued resources carrying the<br>
+VIRTIO_VIDEO_DEQUEUE_FLAG_ERR flag. This flag indicates that the<br>
+particular output frame might be corrupted, but the stream still exists<br>
+and can recover.<br>
+<br>
+\paragraph{Dynamic Parameters Change Event}<br>
+\label{sec:Device Types / Video Device / Device Operation / Device Operation: Standalone Events / Dynamic Parameters Change Event}<br>
+<br>
+A Dynamic Parameters Change (or DPC) event is sent by a decoder device when it<br>
+detects that the parameters of the stream being decoded have changed.<br>
+The device operation is exactly the same as when it receives an in band<br>
+VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS command at the exact same point in the<br>
+stream, that changes OUTPUT queue parameters, see<br>
+\ref{sec:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}.<br>
+<br>
+% TODO add QoS events and overall think about quotas. Codecs are normally<br>
+% limited by bandwidth. How can we accommodate this?<br>
+<br>
+\subsection{Codec-specific parameters}<br>
+\label{sec:Device Types / Video Device / Codec-specific parameters}<br>
+<br>
+The codec-specific controls follow V4L2 controls definitions, that can be<br>
+found in \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+Human-readable descriptions for the codec-specific V4L2 controls can be found<br>
+in \hyperref[intro:V4L2 codec controls]{V4L2 documentation}.<br>
+<br>
+\subsubsection{MPEG2}<br>
+<br>
+MPEG2 capabilities are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_MPEG2_PARAM_PROFILE  1  /* Same as V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE */<br>
+#define VIRTIO_VIDEO_MPEG2_PARAM_LEVEL    2  /* Same as V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL */<br>
+<br>
+struct virtio_video_mpeg2_caps {<br>
+        le32 mpeg2_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_MPEG2_PARAM_*) */<br>
+        le32 mpeg2_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_MPEG2_PROFILE_*) */<br>
+        le32 mpeg2_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_MPEG2_LEVEL_*) */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{mpeg2_params_bitmask}]<br>
+  is a bitmask of supported MPEG2 codec parameters.<br>
+\item[\field{mpeg2_profiles_bitmask}]<br>
+  is a bitmask of supported MPEG2 profiles used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_mpeg2_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{mpeg2_levels_bitmask}]<br>
+  is a bitmask of supported MPEG2 levels used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_mpeg2_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+MPEG2 parameters are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_mpeg2_params {<br>
+        le32 mpeg2_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_MPEG2_PARAM_*) */<br>
+        le32 mpeg2_profile; /* V4L2_MPEG_VIDEO_MPEG2_PROFILE_* */<br>
+        le32 mpeg2_level; /* V4L2_MPEG_VIDEO_MPEG2_LEVEL_* */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{mpeg2_params_bitmask}]<br>
+  is a bitmask of supported MPEG2 codec parameters.<br>
+\item[\field{mpeg2_profile}]<br>
+  is one of the supported MPEG2 profiles, see<br>
+  \field{enum v4l2_mpeg_video_mpeg2_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{mpeg2_level}]<br>
+  is one of the supported MPEG2 levels, see<br>
+  \field{enum v4l2_mpeg_video_mpeg2_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+\subsubsection{MPEG4}<br>
+<br>
+MPEG4 capabilities are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_MPEG4_PARAM_PROFILE  1  /* Same as V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE */<br>
+#define VIRTIO_VIDEO_MPEG4_PARAM_LEVEL    2  /* Same as V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL */<br>
+<br>
+struct virtio_video_mpeg4_caps {<br>
+        le32 mpeg4_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_MPEG4_PARAM_*) */<br>
+        le32 mpeg4_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_MPEG4_PROFILE_*) */<br>
+        le32 mpeg4_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_MPEG4_LEVEL_*) */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{mpeg4_params_bitmask}]<br>
+  is a bitmask of supported MPEG4 codec parameters.<br>
+\item[\field{mpeg4_profiles_bitmask}]<br>
+  is a bitmask of supported MPEG4 profiles used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_mpeg4_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{mpeg4_levels_bitmask}]<br>
+  is a bitmask of supported MPEG4 levels used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_mpeg4_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+MPEG4 parameters are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_mpeg4_params {<br>
+        le32 mpeg4_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_MPEG4_PARAM_*) */<br>
+        le32 mpeg4_profile; /* V4L2_MPEG_VIDEO_MPEG4_PROFILE_* */<br>
+        le32 mpeg4_level; /* V4L2_MPEG_VIDEO_MPEG4_LEVEL_* */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{mpeg4_params_bitmask}]<br>
+  is a bitmask of supported MPEG4 codec parameters.<br>
+\item[\field{mpeg4_profile}]<br>
+  is one of the supported MPEG4 profiles, see<br>
+  \field{enum v4l2_mpeg_video_mpeg4_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{mpeg4_level}]<br>
+  is one of the supported MPEG4 levels, see<br>
+  \field{enum v4l2_mpeg_video_mpeg4_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+\subsubsection{H.264}<br>
+<br>
+H.264 capabilities are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_H264_PARAM_PROFILE  1  /* Same as V4L2_CID_MPEG_VIDEO_H264_PROFILE */<br>
+#define VIRTIO_VIDEO_H264_PARAM_LEVEL    2  /* Same as V4L2_CID_MPEG_VIDEO_H264_LEVEL */<br>
+<br>
+struct virtio_video_h264_caps {<br>
+        le32 h264_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_H264_PARAM_*) */<br>
+        le32 h264_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_H264_PROFILE_*) */<br>
+        le32 h264_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_H264_LEVEL_*) */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{h264_params_bitmask}]<br>
+  is a bitmask of supported H.264 codec parameters.<br>
+\item[\field{h264_profiles_bitmask}]<br>
+  is a bitmask of supported H.264 profiles used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_h264_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{h264_levels_bitmask}]<br>
+  is a bitmask of supported H.264 levels used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_h264_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+H.264 parameters are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_h264_params {<br>
+        le32 h264_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_H264_PARAM_*) */<br>
+        le32 h264_profile; /* V4L2_MPEG_VIDEO_H264_PROFILE_* */<br>
+        le32 h264_level; /* V4L2_MPEG_VIDEO_H264_LEVEL_* */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{h264_params_bitmask}]<br>
+  is a bitmask of supported H.264 codec parameters.<br>
+\item[\field{h264_profile}]<br>
+  is one of the supported H.264 profiles, see<br>
+  \field{enum v4l2_mpeg_video_h264_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{h264_level}]<br>
+  is one of the supported H.264 levels, see<br>
+  \field{enum v4l2_mpeg_video_h264_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+\subsubsection{HEVC}<br>
+<br>
+HEVC capabilities are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_HEVC_PARAM_PROFILE  1  /* Same as V4L2_CID_MPEG_VIDEO_HEVC_PROFILE */<br>
+#define VIRTIO_VIDEO_HEVC_PARAM_LEVEL    2  /* Same as V4L2_CID_MPEG_VIDEO_HEVC_LEVEL */<br>
+<br>
+struct virtio_video_hevc_caps {<br>
+        le32 hevc_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_HEVC_PARAM_*) */<br>
+        le32 hevc_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_HEVC_PROFILE_*) */<br>
+        le32 hevc_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_HEVC_LEVEL_*) */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{hevc_params_bitmask}]<br>
+  is a bitmask of supported HEVC codec parameters.<br>
+\item[\field{hevc_profiles_bitmask}]<br>
+  is a bitmask of supported HEVC profiles used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_hevc_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{hevc_levels_bitmask}]<br>
+  is a bitmask of supported HEVC levels used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_hevc_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+HEVC parameters are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_hevc_params {<br>
+        le32 hevc_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_HEVC_PARAM_*) */<br>
+        le32 hevc_profile; /* V4L2_MPEG_VIDEO_HEVC_PROFILE_* */<br>
+        le32 hevc_level; /* V4L2_MPEG_VIDEO_HEVC_LEVEL_* */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{hevc_params_bitmask}]<br>
+  is a bitmask of supported HEVC codec parameters.<br>
+\item[\field{hevc_profile}]<br>
+  is one of the supported HEVC profiles, see<br>
+  \field{enum v4l2_mpeg_video_hevc_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{hevc_level}]<br>
+  is one of the supported HEVC levels, see<br>
+  \field{enum v4l2_mpeg_video_hevc_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+\subsubsection{VP8}<br>
+<br>
+VP8 capabilities are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_VP8_PARAM_PROFILE  1  /* Same as V4L2_CID_MPEG_VIDEO_VP8_PROFILE */<br>
+<br>
+struct virtio_video_vp8_caps {<br>
+        le32 vp8_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_VP8_PARAM_*) */<br>
+        le32 vp8_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_VP8_PROFILE_*) */<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{vp8_params_bitmask}]<br>
+  is a bitmask of supported VP8 codec parameters.<br>
+\item[\field{vp8_profiles_bitmask}]<br>
+  is a bitmask of supported VP8 profiles used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_vp8_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+VP8 parameters are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_vp8_params {<br>
+        le32 vp8_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_VP8_PARAM_*) */<br>
+        le32 vp8_profile; /* V4L2_MPEG_VIDEO_VP8_PROFILE_* */<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{vp8_params_bitmask}]<br>
+  is a bitmask of supported VP8 codec parameters.<br>
+\item[\field{vp8_profile}]<br>
+  is one of the supported VP8 profiles, see<br>
+  \field{enum v4l2_mpeg_video_vp8_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+\subsubsection{VP9}<br>
+<br>
+VP9 capabilities are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+#define VIRTIO_VIDEO_VP9_PARAM_PROFILE  1  /* Same as V4L2_CID_MPEG_VIDEO_VP9_PROFILE */<br>
+#define VIRTIO_VIDEO_VP9_PARAM_LEVEL    2  /* Same as V4L2_CID_MPEG_VIDEO_VP9_LEVEL */<br>
+<br>
+struct virtio_video_vp9_caps {<br>
+        le32 vp9_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_VP9_PARAM_*) */<br>
+        le32 vp9_profiles_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_VP9_PROFILE_*) */<br>
+        le32 vp9_levels_bitmask; /* Bitmask of MASK(V4L2_MPEG_VIDEO_VP9_LEVEL_*) */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{vp9_params_bitmask}]<br>
+  is a bitmask of supported VP9 codec parameters.<br>
+\item[\field{vp9_profiles_bitmask}]<br>
+  is a bitmask of supported VP9 profiles used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_vp9_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{vp9_levels_bitmask}]<br>
+  is a bitmask of supported VP9 levels used as bit numbers, see<br>
+  \field{enum v4l2_mpeg_video_vp9_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
+<br>
+VP9 parameters are defined as follows:<br>
+<br>
+\begin{lstlisting}<br>
+struct virtio_video_vp9_params {<br>
+        le32 vp9_params_bitmask; /* Bitmask of MASK(VIRTIO_VIDEO_VP9_PARAM_*) */<br>
+        le32 vp9_profile; /* V4L2_MPEG_VIDEO_VP9_PROFILE_* */<br>
+        le32 vp9_level; /* V4L2_MPEG_VIDEO_VP9_LEVEL_* */<br>
+        u8 padding[4];<br>
+};<br>
+\end{lstlisting}<br>
+<br>
+\begin{description}<br>
+\item[\field{vp9_params_bitmask}]<br>
+  is a bitmask of supported VP9 codec parameters.<br>
+\item[\field{vp9_profile}]<br>
+  is one of the supported VP9 profiles, see<br>
+  \field{enum v4l2_mpeg_video_vp9_profile} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\item[\field{vp9_level}]<br>
+  is one of the supported VP9 levels, see<br>
+  \field{enum v4l2_mpeg_video_vp9_level} in<br>
+  \hyperref[intro:V4L2 controls]{V4L2 controls header}.<br>
+\end{description}<br>
diff --git a/device-types/video/device-conformance.tex b/device-types/video/device-conformance.tex<br>
new file mode 100644<br>
index 0000000..8aaf744<br>
--- /dev/null<br>
+++ b/device-types/video/device-conformance.tex<br>
@@ -0,0 +1,22 @@<br>
+\conformance{\subsection}{Video Device Conformance}<br>
+\label{sec:Conformance / Device Conformance / Video Device Conformance}<br>
+<br>
+A video device MUST conform to the following normative statements:<br>
+<br>
+\begin{itemize}<br>
+\item \ref{devicenormative:Device Types / Video Device / Feature bits}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device configuration layout}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Format dependencies}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Raw format capabilities}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Resource capabilities}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Device Commands / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS / VIRTIO_VIDEO_CMD_DEVICE_QUERY_CAPS: Bitrates}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_CREATE}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}<br>
+\item \ref{devicenormative:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}<br>
+\end{itemize}<br>
diff --git a/device-types/video/driver-conformance.tex b/device-types/video/driver-conformance.tex<br>
new file mode 100644<br>
index 0000000..1fe8473<br>
--- /dev/null<br>
+++ b/device-types/video/driver-conformance.tex<br>
@@ -0,0 +1,16 @@<br>
+\conformance{\subsection}{Video Driver Conformance}<br>
+\label{sec:Conformance / Driver Conformance / Video Driver Conformance}<br>
+<br>
+A video driver MUST conform to the following normative statements:<br>
+<br>
+\begin{itemize}<br>
+\item \ref{drivernormative:Device Types / Video Device / Feature bits}<br>
+\item \ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Command Virtqueue}<br>
+\item \ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Event Virtqueue}<br>
+\item \ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DESTROY}<br>
+\item \ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_SET_PARAMS}<br>
+\item \ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_DRAIN}<br>
+\item \ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Stream commands / VIRTIO_VIDEO_CMD_STREAM_RESET}<br>
+\item \ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_ATTACH_BACKING}<br>
+\item \ref{drivernormative:Device Types / Video Device / Device Operation / Device Operation: Resource Commands / VIRTIO_VIDEO_CMD_RESOURCE_QUEUE}<br>
+\end{itemize}<br>
diff --git a/introduction.tex b/introduction.tex<br>
index b7155bf..b378883 100644<br>
--- a/introduction.tex<br>
+++ b/introduction.tex<br>
@@ -101,6 +101,15 @@ \section{Normative References}\label{sec:Normative References}<br>
        \phantomsection\label{intro:SEC1}\textbf{[SEC1]} &<br>
     Standards for Efficient Cryptography Group(SECG), ``SEC1: Elliptic Cureve Cryptography'', Version 1.0, September 2000.<br>
        \newline\url{<a href="https://www.secg.org/sec1-v2.pdf" rel="noreferrer" target="_blank">https://www.secg.org/sec1-v2.pdf</a>}\\<br>
+       \phantomsection\label{intro:V4L2}\textbf{[V4L2]} &<br>
+       Linux V4L2 interface.<br>
+       \newline\url{<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/videodev2.h" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/videodev2.h</a>}\\<br>
+       \phantomsection\label{intro:V4L2 controls}\textbf{[V4L2 Controls]} &<br>
+       Linux V4L2 controls definitions.<br>
+       \newline\url{<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/v4l2-controls.h" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/v4l2-controls.h</a>}\\<br>
+       \phantomsection\label{intro:DRM formats}\textbf{[DRM Formats]} &<br>
+       Linux DRM format definitions.<br>
+       \newline\url{<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h</a>}\\<br>
<br>
 \end{longtable}<br>
<br>
@@ -110,6 +119,18 @@ \section{Non-Normative References}<br>
        \phantomsection\label{intro:Virtio PCI Draft}\textbf{[Virtio PCI Draft]} &<br>
        Virtio PCI Draft Specification<br>
        \newline\url{<a href="http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.5.pdf" rel="noreferrer" target="_blank">http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.5.pdf</a>}\\<br>
+       \phantomsection\label{intro:V4L2 compressed}\textbf{[V4L2 compressed formats]} &<br>
+       Detailed descriptions of V4L2 compressed formats<br>
+       \newline\url{<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst</a>}\\<br>
+       \phantomsection\label{intro:V4L2 RGB}\textbf{[V4L2 RGB formats]} &<br>
+       Detailed descriptions of V4L2 RGB formats<br>
+       \newline\url{<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst</a>}\\<br>
+       \phantomsection\label{intro:V4L2 YUV}\textbf{[V4L2 planar YUV formats]} &<br>
+       Detailed descriptions of V4L2 planar YUV formats<br>
+       \newline\url{<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst</a>}\\<br>
+       \phantomsection\label{intro:V4L2 codec controls}\textbf{[V4L2 codec controls]} &<br>
+       Detailed descriptions of V4L2 controls<br>
+       \newline\url{<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst</a>}\\<br>
 \end{longtable}<br>
<br>
 \section{Terminology}\label{Terminology}<br>
-- <br>
2.34.1<br></blockquote><div><br></div><div>BR,</div><div>Albert </div></div></div>